From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue Mar 14 23:21:58 2006 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue Mar 14 23:21:58 2006 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx@mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue Mar 14 23:21:58 2006 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj@www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue Mar 14 23:21:58 2006 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj@www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx@mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue Mar 14 23:21:58 2006 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj@www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx@mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx@mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue Mar 14 23:21:58 2006 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj@www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue Mar 14 23:21:58 2006 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj@www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx@mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue Mar 14 23:21:58 2006 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj@www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx@mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx@mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue Mar 14 23:21:58 2006 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj@www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue Mar 14 23:21:58 2006 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj@www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue Mar 14 23:21:58 2006 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj@www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx@mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue Mar 14 23:21:58 2006 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj@www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue Mar 14 23:21:58 2006 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj@www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx@mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue Mar 14 23:21:58 2006 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj@www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue Mar 28 18:25:21 2006 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue Mar 28 18:25:22 2006 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx@mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue Mar 28 18:25:22 2006 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj@www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue Mar 28 18:25:22 2006 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj@www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx@mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue Mar 28 18:25:22 2006 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj@www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx@mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx@mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue Mar 28 18:25:22 2006 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj@www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue Mar 28 18:25:22 2006 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj@www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx@mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue Mar 28 18:25:22 2006 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj@www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx@mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx@mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue Mar 28 18:25:22 2006 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj@www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue Mar 28 18:25:22 2006 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj@www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue Mar 28 18:25:22 2006 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj@www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx@mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue Mar 28 18:25:22 2006 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj@www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue Mar 28 18:25:22 2006 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj@www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx@mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue Mar 28 18:25:22 2006 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj@www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue Mar 28 20:17:18 2006 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue Mar 28 20:17:18 2006 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx@mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue Mar 28 20:17:18 2006 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj@www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue Mar 28 20:17:18 2006 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj@www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx@mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue Mar 28 20:17:18 2006 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj@www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx@mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx@mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue Mar 28 20:17:18 2006 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj@www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue Mar 28 20:17:18 2006 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj@www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx@mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue Mar 28 20:17:18 2006 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj@www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx@mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx@mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue Mar 28 20:17:18 2006 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj@www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue Mar 28 20:17:18 2006 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj@www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue Mar 28 20:17:18 2006 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj@www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx@mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue Mar 28 20:17:18 2006 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj@www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue Mar 28 20:17:18 2006 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj@www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx@mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue Mar 28 20:17:18 2006 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj@www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 11:58:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 18:58:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > When setting setReceiveTimeout() to 10sec, it works with RXTX on > Windows ??? > > The OutputBufferNotification() did nothing good. > > any explanation for that ? > > M. > > > Hi Moritz Ah.. The default timeouts and thresholds are not documented. RXTX will probably not match Sun there because I do not know what they should be. That would make sense. If you know what the Sun defaults are, I can change rxtx to match that. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Thu Apr 14 13:02:47 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:02:47 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: On Thu, 14 Apr 2005, Trent Jarvi wrote: > > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > > > When setting setReceiveTimeout() to 10sec, it works with RXTX on > > Windows ??? > > > > The OutputBufferNotification() did nothing good. > > > > any explanation for that ? > > > > M. > > > > > > > > Hi Moritz > > Ah.. The default timeouts and thresholds are not documented. RXTX will > probably not match Sun there because I do not know what they should be. > > That would make sense. If you know what the Sun defaults are, I can > change rxtx to match that. > > Just one more note now that we are looking at timeouts. RXTX timeouts do not offer the granularity that windows can offer. On Unix and Linux, the minimum nonzero timeout is 100 MS. As Java is supposed to be platform neutral, the integer timeout is divided by 100 before even doing the windows or Unix/Linux native calls. Sometimes this causes problems for people that develop on w32 with Sun's CommAPI, set the Timeout to lower numbers then expect Solaris or Linux to behave the same. This is all related to the POSIX termios.c_cc[ VTIME ] behavior. VTIME is defined in deciseconds. Perhaps it would make sense to print a big warning when the modula of timeout/100 is nonzero. if ( timeout % 100 ) System.err.println("[RXTX] Warning Timeout..."); This may not make sense but rxtx sets the w32 [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME as timeout/100. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 13:23:50 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 21:23:50 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> It sure is related to the way RXTX is handling read timeouts. RFAX sets it readTimeout to 1000 with suns commapi. If I increase that number to 10000, everything works fine. If I keep it at 1000 and simply ignore every -1 value received, it does not work although, I'd suppose this would be the same behaviour as setting the readTimeout to infinitely high. If I set disableReadTimeout(), read() still returns -1 if there is no data available (is this correct ?) but If I ignore those -1 values, the software works perfectly ! M. Am 14.04.2005 um 21:02 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Trent Jarvi wrote: > >> >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> When setting setReceiveTimeout() to 10sec, it works with RXTX on >>> Windows ??? >>> >>> The OutputBufferNotification() did nothing good. >>> >>> any explanation for that ? >>> >>> M. >>> >>> >>> >> >> Hi Moritz >> >> Ah.. The default timeouts and thresholds are not documented. RXTX >> will >> probably not match Sun there because I do not know what they should >> be. >> >> That would make sense. If you know what the Sun defaults are, I can >> change rxtx to match that. >> >> > > Just one more note now that we are looking at timeouts. RXTX timeouts > do > not offer the granularity that windows can offer. On Unix and Linux, > the > minimum nonzero timeout is 100 MS. As Java is supposed to be platform > neutral, the integer timeout is divided by 100 before even doing the > windows or Unix/Linux native calls. > > Sometimes this causes problems for people that develop on w32 with > Sun's > CommAPI, set the Timeout to lower numbers then expect Solaris or Linux > to > behave the same. > > This is all related to the POSIX termios.c_cc[ VTIME ] behavior. > VTIME is > defined in deciseconds. Perhaps it would make sense to print a big > warning when the modula of timeout/100 is nonzero. > > if ( timeout % 100 ) > System.err.println("[RXTX] Warning Timeout..."); > > This may not make sense but rxtx sets the w32 > [Read/Write]TotalTimeoutConstant to VTIME*100 after calculating VTIME > as > timeout/100. > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 13:42:51 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 20:42:51 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <07bccd05feb498dc37f063c2cf1362c1@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > It sure is related to the way RXTX is handling read timeouts. > > RFAX sets it readTimeout to 1000 with suns commapi. > > If I increase that number to 10000, everything works fine. > > If I keep it at 1000 and simply ignore every -1 value received, it does > not work although, I'd suppose this would be the same behaviour as > setting the readTimeout to infinitely high. > > If I set disableReadTimeout(), read() still returns -1 if there is no > data available (is this correct ?) but If I ignore those -1 values, the > software works perfectly ! > Hi Moritz The behavior of read is dependant upon the timeout and threshold. see the getInputStream() comments here for more information. http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html What you mention does not sound correct, but perhaps you could be more specific after seeing the chart and comments. Perhaps another error is occuring during read() that is not handled right. I _think_ rxtx is setting up the COMMTIMEOUTS structure correctly in termios.c:tcsetattr(). -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 14:34:31 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 22:34:31 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> Message-ID: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> I call disableReceiveThreshold() and disableReceiveTimeout() and still read() returns -1 when no data is available from that port. When enableReceiveTimeout() is set to some value, read() actually blocks for that number of ms specified. FlowControl is set to RTS/CTS on Input and Output. Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. M. Am 14.04.2005 um 21:42 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> It sure is related to the way RXTX is handling read timeouts. >> >> RFAX sets it readTimeout to 1000 with suns commapi. >> >> If I increase that number to 10000, everything works fine. >> >> If I keep it at 1000 and simply ignore every -1 value received, it >> does >> not work although, I'd suppose this would be the same behaviour as >> setting the readTimeout to infinitely high. >> >> If I set disableReadTimeout(), read() still returns -1 if there is no >> data available (is this correct ?) but If I ignore those -1 values, >> the >> software works perfectly ! >> > > Hi Moritz > > The behavior of read is dependant upon the timeout and threshold. > > see the getInputStream() comments here for more information. > > http://java.sun.com/products/javacomm/javadocs/javax/comm/CommPort.html > > What you mention does not sound correct, but perhaps you could be more > specific after seeing the chart and comments. Perhaps another error is > occuring during read() that is not handled right. I _think_ rxtx is > setting up the COMMTIMEOUTS structure correctly in > termios.c:tcsetattr(). > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 15:32:29 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 22:32:29 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> <07bccd05feb498dc37f063c2cf1362c1@gmx.de> <072dfe44ad02131984ca30fb22ff5bf4@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > I call disableReceiveThreshold() and disableReceiveTimeout() and still > read() returns -1 when no data is available from that port. > > When enableReceiveTimeout() is set to some value, read() actually > blocks for that number of ms specified. > > FlowControl is set to RTS/CTS on Input and Output. > > Is that reproducable ? I tried that with the latest RXTX 2.1.-7pre17. > > M. > Hi Martin I'm going to need to dig up a windows box and try to reproduce this. My guess is there is something in termios.c:serial_read() thats letting the timeout slip past. It may even be an unhandled error condition. I cant see the error but I suspect thats where it is comming from. RXTX has some logic in there to handles timeouts. I wont be able to look at this until the weekend though. If you are looking at the code, it should be the O_NOBOCK case with c_cc[VTIME] = 0. The code is trying to block until cbInQue is the size requested. That first part of serial_read blocking until the data is in the queue is what I would be looking at to see why it failed. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 08:56:14 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 16:56:14 +0200 Subject: [Rxtx] RFax with RXTX on Windows Message-ID: Hi List, I just tried sending faxes with Java on Windows using the rfax library. Unfortunately, this doesn't work with the RXTX-Comm libraries The Transfer just stops after 2-3 Lines of Fax and the software tells me that the fax was successfully sent. It does work with RXTX from MacOS X. It also works with SUNs COMMAPI Classes on Windows. Has anybody heared of this problem or can image what could cause this kind of behaviour ? Thanks Moritz From moritz.gmelin at gmx.de Tue Apr 12 09:51:29 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 17:51:29 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: Uh, rfax is sending very large data packets (> 5000 bytes) at once when it is transferring the FAX-Data. This seems to be broken in Windows with RXTX. Can anybody confirm this problem ? M. Am 12.04.2005 um 16:56 schrieb Moritz Gmelin: > Hi List, > > I just tried sending faxes with Java on Windows using the rfax > library. Unfortunately, this doesn't work with the RXTX-Comm libraries > The Transfer just stops after 2-3 Lines of Fax and the software tells > me that the fax was successfully sent. It does work with RXTX from > MacOS X. It also works with SUNs COMMAPI Classes on Windows. > Has anybody heared of this problem or can image what could cause this > kind of behaviour ? > > Thanks > > Moritz > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Apr 12 12:14:08 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Apr 2005 19:14:08 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: On Tue, 12 Apr 2005, Moritz Gmelin wrote: > Uh, > > rfax is sending very large data packets (> 5000 bytes) at once when it > is transferring the FAX-Data. > This seems to be broken in Windows with RXTX. > Can anybody confirm this problem ? > Hi Moritz It sounds like the writes() are overflowing the output buffer. RXTX does not have buffers so without flow control, I can picture this happening. You could try turning on hardware flow control, modify RXTXPort.java to break up the writes and use output buffer empty events to throttle it, or a circular buffer could be implemented in the native code. "Up to 16 bytes can be written at once to the transmitter FIFO buffer while processing one transmitter interrupt if an 16550 UART is used, while the 16650 can write up to 32 bytes at once, and the 16750 can write up to 64 bytes." http://www.marshallsoft.com/rs232.htm -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Tue Apr 12 12:44:42 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Tue, 12 Apr 2005 20:44:42 +0200 Subject: [Rxtx] RFax with RXTX on Windows ---- RXTX Bug in Windows ? In-Reply-To: References: Message-ID: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Flow Control is set to RTS_CTS on Input and Output while this is happening ! M. Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > On Tue, 12 Apr 2005, Moritz Gmelin wrote: > >> Uh, >> >> rfax is sending very large data packets (> 5000 bytes) at once when it >> is transferring the FAX-Data. >> This seems to be broken in Windows with RXTX. >> Can anybody confirm this problem ? >> > > Hi Moritz > > It sounds like the writes() are overflowing the output buffer. > > RXTX does not have buffers so without flow control, I can picture this > happening. > > You could try turning on hardware flow control, modify RXTXPort.java to > break up the writes and use output buffer empty events to throttle it, > or > a circular buffer could be implemented in the native code. > > "Up to 16 bytes can be written at once to the transmitter FIFO buffer > while processing one transmitter interrupt if an 16550 UART is used, > while > the 16650 can write up to 32 bytes at once, and the 16750 can write up > to > 64 bytes." > > > http://www.marshallsoft.com/rs232.htm > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 02:30:53 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 10:30:53 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: Hi, even after breaking down the large data into packets of 16 bytes followed by a flush() on the stream, data is still lost. While I cannot reproduce this problem with my PC and my Modem, a customer is reporting this. Would it help to work with the notifyOnOutputBufferEmpty() to wait until everything is written ? M. Am 12.04.2005 um 20:44 schrieb Moritz Gmelin: > Flow Control is set to RTS_CTS on Input and Output while this is > happening ! > > M. > > Am 12.04.2005 um 20:14 schrieb Trent Jarvi: > >> On Tue, 12 Apr 2005, Moritz Gmelin wrote: >> >>> Uh, >>> >>> rfax is sending very large data packets (> 5000 bytes) at once when >>> it >>> is transferring the FAX-Data. >>> This seems to be broken in Windows with RXTX. >>> Can anybody confirm this problem ? >>> >> >> Hi Moritz >> >> It sounds like the writes() are overflowing the output buffer. >> >> RXTX does not have buffers so without flow control, I can picture this >> happening. >> >> You could try turning on hardware flow control, modify RXTXPort.java >> to >> break up the writes and use output buffer empty events to throttle >> it, or >> a circular buffer could be implemented in the native code. >> >> "Up to 16 bytes can be written at once to the transmitter FIFO buffer >> while processing one transmitter interrupt if an 16550 UART is used, >> while >> the 16650 can write up to 32 bytes at once, and the 16750 can write >> up to >> 64 bytes." >> >> >> http://www.marshallsoft.com/rs232.htm >> >> >> >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> http://mail.linuxgrrls.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Apr 14 03:16:03 2005 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 14 Apr 2005 10:16:03 +0100 (BST) Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: On Thu, 14 Apr 2005, Moritz Gmelin wrote: > Hi, > > even after breaking down the large data into packets of 16 bytes > followed by a flush() on the stream, data is still lost. > While I cannot reproduce this problem with my PC and my Modem, a > customer is reporting this. > Would it help to work with the notifyOnOutputBufferEmpty() to wait > until everything is written ? > Hi Moritz I'm curious what modem they have. We will probably see this again. When you said the Sun driver was working, was that on your customers machine or did you see rxtx behaving differently that Sun on your machine? The notifyOnOutputBufferEmpty() is used fairly often by some. It should be reliable. I tried looking at the rxtx code and did not see anything obvious that could be causing a problem. There is a great deal of debugging code in there thats turned off. hardware flow control should deal with the problem so I'm somewhat confused. I glanced at the software web site you mentioned. I don't think its safe for me to download their software given their license regarding design, concepts, ... It would just be looking for trouble for me to examine the product. The last time I heard about something like this, someone was sending 64 meg files related with GPS info on linux many years ago. -- Trent Jarvi taj at www.linux.org.uk From moritz.gmelin at gmx.de Thu Apr 14 03:30:00 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 11:30:00 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> Message-ID: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> The sun API behaves differently than RXTX on my machine. So this is reproducable. On my machine (with my Modem) it was able to reduce packet size to 100 bytes, which made it work. On the customers machine, this did not help. Only switching to SUN solved the problem for him. I'll try to add the notification now and see if this helps. M. Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > On Thu, 14 Apr 2005, Moritz Gmelin wrote: > >> Hi, >> >> even after breaking down the large data into packets of 16 bytes >> followed by a flush() on the stream, data is still lost. >> While I cannot reproduce this problem with my PC and my Modem, a >> customer is reporting this. >> Would it help to work with the notifyOnOutputBufferEmpty() to wait >> until everything is written ? >> > > Hi Moritz > > I'm curious what modem they have. We will probably see this again. > When > you said the Sun driver was working, was that on your customers > machine or > did you see rxtx behaving differently that Sun on your machine? > > The notifyOnOutputBufferEmpty() is used fairly often by some. It > should > be reliable. I tried looking at the rxtx code and did not see anything > obvious that could be causing a problem. There is a great deal of > debugging code in there thats turned off. hardware flow control should > deal with the problem so I'm somewhat confused. > > I glanced at the software web site you mentioned. I don't think its > safe > for me to download their software given their license regarding design, > concepts, ... It would just be looking for trouble for me to examine > the > product. > > The last time I heard about something like this, someone was sending 64 > meg files related with GPS info on linux many years ago. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at mail.linuxgrrls.org > http://mail.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Thu Apr 14 10:36:33 2005 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 14 Apr 2005 18:36:33 +0200 Subject: [Rxtx] RFax with RXTX on Windows ----Problem persists In-Reply-To: <2a484563f2be2bff99f8adf21d4245f0@gmx.de> References: <4f3cf8f7dc20c3a6ed36b92f0cb2b045@gmx.de> <2a484563f2be2bff99f8adf21d4245f0@gmx.de> Message-ID: When setting setReceiveTimeout() to 10sec, it works with RXTX on Windows ??? The OutputBufferNotification() did nothing good. any explanation for that ? M. Am 14.04.2005 um 11:30 schrieb Moritz Gmelin: > The sun API behaves differently than RXTX on my machine. So this is > reproducable. > On my machine (with my Modem) it was able to reduce packet size to 100 > bytes, which made it work. > On the customers machine, this did not help. Only switching to SUN > solved the problem for him. > > I'll try to add the notification now and see if this helps. > > M. > > > > Am 14.04.2005 um 11:16 schrieb Trent Jarvi: > >> On Thu, 14 Apr 2005, Moritz Gmelin wrote: >> >>> Hi, >>> >>> even after breaking down the large data into packets of 16 bytes >>> followed by a flush() on the stream, data is still lost. >>> While I cannot reproduce this problem with my PC and my Modem, a >>> customer is reporting this. >>> Would it help to work with the notifyOnOutputBufferEmpty() to wait >>> until everything is written ? >>> >> >> Hi Moritz >> >> I'm curious what modem they have. We will probably see this again. >> When >> you said the Sun driver was working, was that on your customers >> machine or >> did you see rxtx behaving differently that Sun on your machine? >> >> The notifyOnOutputBufferEmpty() is used fairly often by some. It >> should >> be reliable. I tried looking at the rxtx code and did not see >> anything >> obvious that could be causing a problem. There is a great deal of >> debugging code in there thats turned off. hardware flow control >> should >> deal with the problem so I'm somewhat confused. >> >> I glanced at the software web site you mentioned. I don't think its >> safe >> for me to download their software given their license regarding >> design, >> concepts, ... It would just be looking for trouble for me to examine >> the >> product. >> >> The last time I heard about something like this, someone was sending >> 64 >> meg files related with GPS info on linux many years ago. >> >> -- >> Trent Jarvi >> taj at www.linux.org.uk >> _______________________________________________ >> Rxtx mailing list >> Rxtx at mail.linuxgrrls.org >> h