开云体育

Well a friend just got his decoder pro, so I went to help. I am a MAC guy
but I am an NT Lan Admin at work :( Anyway we spent 1.5 hours changing this
and that. What finally worked was resetting the com ports in XP to defaults
and using the following preferences for Decoder pro:

Locobuffer
COM1
57600
NO FLOW CONTROL (This is the unrecommended setting)
DCS 100

Worked great after that....Might be of some help...maybe not

--
William, Charleston, SC
N scale & Digitrax Chief

Bob,

This is starting to smell like the Java Comm API is not correctly handling
the hardware handshake configuration or XP is doing something different.

Looking at LocoBufferAdapter.java you appear to only be checking CTS for CTS
before sending and enabling CTS handshake on open, which is what I would
expect, so I wonder if Bill's boys in their wisdom have _fixed_ something in
XP such that it now requires the DTR/DSR and DCD lines to also be looped.

Actually come to think of it, I modified my LocoBuffer(s) to have a low
value resistor linking pins 6 and 20 and I may have also linked in pin 8 as
well. I did this way back when there was some discussion around being able
to detect if a LocoBuffer is present by sensing DTR/DSR. I think some people
were pretty adament about it being a necessity for good software design and
robustness etc.

I will have to check when I get home, but that may explain why my units at
least have continued to work fine all this time even if a subtle change has
crept in.

Can anyone confirm is these problems have only surfaced on Windows XP or are
they not Windows version specific?

I'm on Win2K

Alex

What finally worked was resetting the com ports in XP
to defaults
and using the following preferences for Decoder pro:

Locobuffer
COM1
57600
NO FLOW CONTROL (This is the unrecommended setting)
DCS 100

No Flow Control was the setting that got mine going, too (FYI: a PII 200mhz
desktop with a serial card I purchased from Loy's). Maybe anyone with com
port problems should be experimenting with this setting along with the other
more discussed ones.

Aloha,
Jim

I discovered DecoderPro just a couple days ago. After a couple false starts
I got it up and running yesterday. It is on an early-Pentium laptop running
W98SE. I'm using an MS100 to connect to my Digitrax Chief. Other than
taking a long time to start running after double clicking the icon it works
just fine. I'm added five locomotives to the roster, changing the speed
curve on one. So far I'm very happy with it.



MB

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello Alex,

This is a problem with the Locobuffer. Depending on how the computer
hardware deals with a unconnected signal, it can be either high or low.

I had to connect the CTS to the DSR _and_ the DCD (CD).

Anyway, I added a jumper to the Locobuffer to connect pins 5,6 & 8. It
now works nicely.


JBB


Wednesday, November 6, 2002, 10:22:12 PM, you wrote:

AS> Bob,

AS> This is starting to smell like the Java Comm API is not correctly handling
AS> the hardware handshake configuration or XP is doing something different.

AS> Looking at LocoBufferAdapter.java you appear to only be checking CTS for CTS
AS> before sending and enabling CTS handshake on open, which is what I would
AS> expect, so I wonder if Bill's boys in their wisdom have _fixed_ something in
AS> XP such that it now requires the DTR/DSR and DCD lines to also be looped.

AS> Actually come to think of it, I modified my LocoBuffer(s) to have a low
AS> value resistor linking pins 6 and 20 and I may have also linked in pin 8 as
AS> well. I did this way back when there was some discussion around being able
AS> to detect if a LocoBuffer is present by sensing DTR/DSR. I think some people
AS> were pretty adament about it being a necessity for good software design and
AS> robustness etc.

AS> I will have to check when I get home, but that may explain why my units at
AS> least have continued to work fine all this time even if a subtle change has
AS> crept in.

AS> Can anyone confirm is these problems have only surfaced on Windows XP or are
AS> they not Windows version specific?

AS> I'm on Win2K

AS> Alex

At 4:22 PM +1300 11/7/02, Alex Shepherd wrote:

Bob,

This is starting to smell like the Java Comm API is not correctly handling
the hardware handshake configuration or XP is doing something different.

Looking at LocoBufferAdapter.java you appear to only be checking CTS for CTS
before sending and enabling CTS handshake on open, which is what I would
expect, so I wonder if Bill's boys in their wisdom have _fixed_ something in
XP such that it now requires the DTR/DSR and DCD lines to also be looped.

DecoderPro and the Java Comm library are trying to set the serial port to:

Flow control to the LocoBuffer; don't send unless CTS (Clear
To Send) is active.

Ignore flow control from the LocoBuffer, receive characters
any time.

What seems to be happening is that the second part is working, but in certain situations the first part becomes "don't send unless CTS and DSR are active" (DSR is Data Set Ready; "Data Set" was the original telco name for what we now call a modem). I don't have a lot of control over this, and think it must somehow be happening in the OS or serial driver level.

Does anybody know if there are Windows configuration options that might be effecting this?

Bob
--
--------------
Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957)