Locked
Re: USB-to-Serial converters handshake line termination
Alex,
Any chance you could try the latest FTDI driver and temporarily remove
handshake line jumpers you added on the LB? I was hoping to find out if the
handshake problem was in the FTDI hardware/driver or in the SDK/ JavaComm
software. I suspect software since it also has been reported on native
serial ports, but thought the test would be worthwhile.
Robin
toggle quoted message
Show quoted text
-----Original Message-----
From: Alex Shepherd [mailto:ashepherd@...]
Sent: Saturday, November 09, 2002 3:42 AM
To: jmriusers@...
Subject: Re: [jmriusers] USB-to-Serial converters handshake line
termination
The DecoderPro install instructions don't talk about Windows drivers.
Should they?
Well I'm not really sure you could say much generally except for known bad
hardware/software combinations.
So far what I have seems to work with the simple test I gave it,
but I only
got it recently as I am running out of serial ports.
I think if we go with a note to say that you should link the appropriate
pins either in the cable or on LB and run at 19200 then this should suit
most systems.
People can try the faster baud if they want, but it won't make much
difference as it still has to dribble out at 1666 onto the LN, but I guess
the latency is a fraction less :-)
Alex
To unsubscribe from this group, send an email to:
jmriusers-unsubscribe@...
Your use of Yahoo! Groups is subject to
|
Locked
Re: Roster order (was Re: Soundtraxx DSD-AT100LC)
At 2:27 PM -0800 11/4/02, Mike Davison wrote: The Java guidelines were probably written by unix geeks, rather than humans.
(Insert smiley face - I confess to being a unix geek) I too suggest simple
alpha ordering. In fact, it would be a good idea to completely ignore alpha
case in roster entry names. ie.: SoundTraxx == soundtraxx == SOUNDTRAXX...
This would keep me from creating a roster entry named xyz-123 and XYZ-123 for
the same locomotive/decoder. OK, done. It'll be in the next test version released, and is in CVS now. At 11:59 AM +1300 11/5/02, Alex Shepherd wrote: Does DecoderPro do anything to avoid upper/lower case filename issues now
for filenames? What happens if I save a decoder under a different case
name - do both entries try and share the same filename? It (is supposed to) notice that the file already exists and pick a different name. It's also supposed to prevent you from changing the ID of a roster entry to one that already exists. I haven't really tested that in a long time, however. Bob -- -------------- Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957)
|
Locked
Re: USB-to-Serial converters handshake line termination
The DecoderPro install instructions don't talk about Windows drivers.
Should they?
Well I'm not really sure you could say much generally except for known bad hardware/software combinations. So far what I have seems to work with the simple test I gave it, but I only got it recently as I am running out of serial ports. I think if we go with a note to say that you should link the appropriate pins either in the cable or on LB and run at 19200 then this should suit most systems. People can try the faster baud if they want, but it won't make much difference as it still has to dribble out at 1666 onto the LN, but I guess the latency is a fraction less :-) Alex
|
Locked
Re: USB-to-Serial converters handshake line termination
At 4:17 PM -0700 11/8/02, Robin Becker wrote: Ok, so I can see a potential problem under the following circumstances:
If:
the USB-to-Serial device mfr has provided an RS232 connection to the DSR and
DCD pins on the FTDI device (quite possible),
and
if the dataset (LocoBuffer) isn't driving those lines (which we know - the
LB only supports CTS),
and
if those lines float at the "wrong" level,
and
if the device driver software enables those control inputs,
then
the PC driver would think that the LocoBuffer is not ready to receive and
the serial data output from the PC would not be transmitted.
This is all consisted with the reported behavior, namely that wiring the DSR
and DCD pins to the CTS pin on the LocoBuffer fixes the problem. The open
question is whether the device driver provides any means of disabling the
DSR and DCD via software while still enabling CTS, which would be the most
desirable solution. Sounds like that's definitely what's going on. The LocoBuffer driver code tells the Java comm library to set hardware flow control outbound (to the LocoBuffer), and not to set it outbound. But we don't have the source for that library, and I don't know whether it actually keeps those two separate directions when talking to Windows. Some of the reported problems have been with native serial ports on laptops, but the logic is probably similar. If the Java comm library or the OS isn't keeping the two directions separate, the missing control leads from the LocoBuffer will cause a problem. Setting "no flow control" will bypass it for DecoderPro, as DecoderPro only sends individual messages (e.g. sends the message and waits for the reply). The LocoBuffer shouldn't get stacked up. But other JMRI programs aren't that simple, and a lot of the LocoBuffer's advantages will be lost if we can't be sure it won't lose messages. Don't know if this affect anything but the drivers on the FTDI website are
more recent than those at the DSE link you provided. (FTDI says they are
now WHQL certified for WinXP) Anyone having problems with a USB-serial
device using an FTDI chip might want to check this site for the latest
driver.
The DecoderPro install instructions don't talk about Windows drivers. Should they? Bob -- -------------- Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957)
|
Locked
Re: Program error -Timeout talking to Command Station
At 5:27 PM -0600 11/4/02, Michael Beckemeier wrote: Is it just me, or are virtually all of the communications problems being seen unique to the various Digitrax systems?
Are other systems (Lenz, NCE, etc) having problems? Unfortunately, yes. Right now, I'm working a problem with a Wangrow unit that talks to one Macintosh and not another, a Lenz system that programs once but requires power-cycling the LI100 interface to program again, and an EasyDCC system that doesn't turn the track power back on properly. But LocoBuffer problems have recently been causing a lot of traffic. In part that's because they've been hard to figure out, so they make a lot of emails go back and forth. And we used to have _lots_ of problems with the MS100 until we got that sorted out with the help of a bunch of people. I don't know that the Digitrax system has more or less problems per user than the others. It's hard for me to know how many people are using DecoderPro with which system, because I don't tend to hear when it just works. As the program moves forward, features tend to be present in the Digitrax code first. For example, the "speedometer" is still LocoNet-specific, the throttle that Glen Oberhauser is working on is being written for the LocoNet first, etc. That's mostly because people vote with their feet, and work on code for the system that's most directly useful to them. And so far, most of the people who've contributed code have Digitrax systems. (Although people with NCE and EasyDCC systems have also made important contributions, and I don't even know what system some of the people who have contributed decoder files use) Bob -- -------------- Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957)
|
Locked
Re: FAQ/Trouble Shooting LOG
That would be great! There are lots of people here willing to help with details, etc, but if you could pull things together that would be a big help.
Bob
toggle quoted message
Show quoted text
At 3:01 PM -0500 11/8/02, Maloney, Michael wrote: I don't have a tons of time myself, but would be willing to give it a
whack...
-----Original Message-----
From: Bob Jacobsen [mailto:Bob_Jacobsen@...]
Sent: Friday, November 08, 2002 2:18 PM
To: jmriusers@...
Subject: Re: [jmriusers] FAQ/Trouble Shooting LOG
At 1:34 PM -0800 11/6/02, Mark Gurries wrote:
Should someone be keeping a FAQ/Trouble shooting Log for each thing we
learn in terms of system setup? Take error messages and translated
them into check actions ect.... I hate to see BOB spend lots of time
in the future addressing common communication problems.
The log should include accessories Q&A such a Locobuffer setup info and
checks. Same with USB to Serial Adapters. You get the ideas.
Personally I do not have the time, but maybe others do. In the end I
hope that this file be included with the install as part of the
documentation.
Just an Idea... And a _very_ good idea. I've put a little of this info onto the web
pages, but if somebody wanted to write a section of the manual on
troubleshooting, it would help a bunch of people.
Unfortunately, I'm having trouble even keeping up with the email, as
this late reply attests. There's this blasted day job....
--
--------------
Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957)
|
Locked
Re: LocoBuffer/Decoder Pro Problem
Thanks Bob:
Hopefully, Robin Becker can help me out when I get back on Nov 12 Tuesday. I'm in Phoenix, AZ. Thanks again.
Bill
toggle quoted message
Show quoted text
----- Original Message -----
From: Bob Jacobsen
To: jmriusers@...
Sent: Friday, November 08, 2002 12:26 PM
Subject: Re: [jmriusers] LocoBuffer/Decoder Pro Problem
At 6:40 AM -0700 11/8/02, billroger wrote:
>And of course I have never been able to program a decoder.
You've been incredibly patient through all this.
Do you happen to be located in California? If so, maybe I should
drop by with some test equipment and try to figure out what's going
wrong.
I live in Berkeley, and get around most of Northern California for
work. And this weekend I'll be in Anaheim, and could free up a
couple hours if you're somewhere in the southern part of the state.
Bob
--
--------------
Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957)
To unsubscribe from this group, send an email to:
jmriusers-unsubscribe@...
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
|
Locked
Re: LocoBuffer/Decoder Pro Problem
Jon:
I have to go away for a few days will return and pick this up on Tuesday Nov 12.
Bill
toggle quoted message
Show quoted text
----- Original Message -----
From: Jon Miller
To: jmriusers@...
Sent: Friday, November 08, 2002 12:49 PM
Subject: Re: [jmriusers] LocoBuffer/Decoder Pro Problem
I wish he was Bob but Bill's in AZ!
Jon Miller
AT&SF
For me time has stopped in 1941
Digitrax DCC owner, Chief/Zephyr systems
NMRA Life member #2623
Member SFRH&MS
To unsubscribe from this group, send an email to:
jmriusers-unsubscribe@...
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
|
Locked
Windows serial port handshaking control
Bob et al,
I tried to research the serial handshaking questions on MSDN to learn about
DSR vs CTS control in reference to the reports received with USB-to-Serial
devices. I think this may come back to the capabilities of the comm library
DecoderPro uses? The Windows SDK uses a DCB to control serial port
function. The following is the description of members of the DCB structure
relevant to flow control from MSDN. This info does seem to establish that
separate control for CTS and DSR is provided by the SDK. Whether the
DecoderPro serial comm library supports access to this is another question.
Robin Becker
Tucson, AZ
following info from
dcb_str.asp
fOutxCtsFlow
If this member is TRUE, the CTS (clear-to-send) signal is monitored for
output flow control. If this member is TRUE and CTS is turned off, output is
suspended until CTS is sent again.
fOutxDsrFlow
If this member is TRUE, the DSR (data-set-ready) signal is monitored for
output flow control. If this member is TRUE and DSR is turned off, output is
suspended until DSR is sent again.
fDtrControl
DTR (data-terminal-ready) flow control. This member can be one of the
following values.
DTR_CONTROL_DISABLE Disables the DTR line when the device is opened and
leaves it disabled.
DTR_CONTROL_ENABLE Enables the DTR line when the device is opened and leaves
it on.
DTR_CONTROL_HANDSHAKE Enables DTR handshaking. If handshaking is enabled, it
is an error for the application to adjust the line by using the
EscapeCommFunction function.
fDsrSensitivity
If this member is TRUE, the communications driver is sensitive to the state
of the DSR signal. The driver ignores any bytes received, unless the DSR
modem input line is high.
fRtsControl
RTS (request-to-send) flow control. This member can be one of the following
values.
RTS_CONTROL_DISABLE Disables the RTS line when the device is opened and
leaves it disabled.
RTS_CONTROL_ENABLE Enables the RTS line when the device is opened and leaves
it on.
RTS_CONTROL_HANDSHAKE Enables RTS handshaking. The driver raises the RTS
line when the "type-ahead" (input) buffer is less than one-half full and
lowers the RTS line when the buffer is more than three-quarters full. If
handshaking is enabled, it is an error for the application to adjust the
line by using the EscapeCommFunction function.
RTS_CONTROL_TOGGLE Windows NT/2000/XP: Specifies that the RTS line will be
high if bytes are available for transmission. After all buffered bytes have
been sent, the RTS line will be low.
|
Locked
USB-to-Serial converters handshake line termination
Alan,
As you noted your USB-to-Serial converter uses an FTDI part. Here's the
text on handshaking that went along with the reference design on the FTDI
website:
"RTS / CTS handshaking is used in this example. If the MCU has no dedicated
handshaking signals then
general purpose IO pins can usually be used to implement the handshaking. If
the MCU is guaranteed to
accept data sent from the FT232BM at the programmed baud rate, then a single
wire handshake will do
(tie CTS# of the FT232BM to GND ).
"When RTS/CTS hardware handshaking is enabled CTS# can be used to stop the
FT232BM transmitting
data to the MCU / external logic. When CTS# is active ( low ) the FT232BM
will transmit any data in it???s
internal buffers. On taking CTS# high, the FT232BM will stop transmitting
data. Due to the asynchronous
nature of the interface, there is a latency of 0 to 3 characters between
taking CTS# high and data
transmission stopping. The FT232BM drives RTS# high when the available
buffer space inside the device
drops below 32 bytes. This allows the MCU / logic to continue to send up to
30 characters to the FT232BM
after RTS# goes high without causing buffer over-run.
(The inverted signal CTS# above refers to the logic level of the signal at
the pin on the FTDI chip, not the raw RS232 signal)
Ok, so I can see a potential problem under the following circumstances:
If:
the USB-to-Serial device mfr has provided an RS232 connection to the DSR and
DCD pins on the FTDI device (quite possible),
and
if the dataset (LocoBuffer) isn't driving those lines (which we know - the
LB only supports CTS),
and
if those lines float at the "wrong" level,
and
if the device driver software enables those control inputs,
then
the PC driver would think that the LocoBuffer is not ready to receive and
the serial data output from the PC would not be transmitted.
This is all consisted with the reported behavior, namely that wiring the DSR
and DCD pins to the CTS pin on the LocoBuffer fixes the problem. The open
question is whether the device driver provides any means of disabling the
DSR and DCD via software while still enabling CTS, which would be the most
desirable solution.
Don't know if this affect anything but the drivers on the FTDI website are
more recent than those at the DSE link you provided. (FTDI says they are
now WHQL certified for WinXP) Anyone having problems with a USB-serial
device using an FTDI chip might want to check this site for the latest
driver.
Finally I thought it might be intersting to note the MS100 serial port
requirements:
DB25 DB9
Pin Pin Description
2 3 TxD - Data out to Loconet
3 2 RxD - Data to PC from Loconet
4 7 RTS from PC - Must always be High since it provides 12 VDC
'bias'
for input signals to the MS-100.
5 8 CTS to PC - Follows the DCC signal on pin 1 (white) of the
Loconet
cable.
6 6 DSR to PC - Follows DTR thru a 47k resistor to allow detecting
if
an MS-100 is plugged in to the PC. It may NOT follow in all
cases
due to the size of the resistor and the unit loads presented by
some
serial port hardware and, therefore, may not be a reliable
method of
detecting the existence of an MS-100.
7 5 Ground
8 1 DCD to PC - Follows loconet (RxD) signal.
20 4 DTR from PC - MUST ALWAYS BE LOW, it provides -12 VDC 'pulldown
power'
to the MS-100.
Robin Becker
Tucson, AZ
D&RGW Model Railroad Layout
toggle quoted message
Show quoted text
-----Original Message-----
From: Alex Shepherd [mailto:ashepherd@...]
Sent: Friday, November 08, 2002 3:13 PM
To: jmriusers@...
Subject: Re: [jmriusers] DecoderPro communications problems & request
for info
This problem has been reported twice, both on Macintosh. If anybody
uses a USB adapter on Windows or Linux, would you please let me know
whether it's working or not at 57,600? My USB to RS232 adaptor seems to work ok at 57600 and with hardware
handshake enables, but my LocoBuffer already has the handshake
pins linked.
The USB adaptor is an OEMed unit, but it says it uses the FT8U232AM
dedicated USB UART
See: DSE Adaptor USB to Serial U205
Alex
To unsubscribe from this group, send an email to:
jmriusers-unsubscribe@...
Your use of Yahoo! Groups is subject to
|
Locked
Re: DecoderPro communications problems & request for info
This problem has been reported twice, both on Macintosh. If anybody
uses a USB adapter on Windows or Linux, would you please let me know
whether it's working or not at 57,600? My USB to RS232 adaptor seems to work ok at 57600 and with hardware handshake enables, but my LocoBuffer already has the handshake pins linked. The USB adaptor is an OEMed unit, but it says it uses the FT8U232AM dedicated USB UART See: DSE Adaptor USB to Serial U205 Alex
|
Locked
Re: LocoBuffer/Decoder Pro Problem
Jon,
Anywhere near me?
Robin Becker
Tucson, AZ
D&RGW Model Railroad Layout
toggle quoted message
Show quoted text
-----Original Message-----
From: Jon Miller [mailto:atsf@...]
Sent: Friday, November 08, 2002 12:50 PM
To: jmriusers@...
Subject: Re: [jmriusers] LocoBuffer/Decoder Pro Problem
I wish he was Bob but Bill's in AZ!
Jon Miller
AT&SF
For me time has stopped in 1941
Digitrax DCC owner, Chief/Zephyr systems
NMRA Life member #2623
Member SFRH&MS
To unsubscribe from this group, send an email to:
jmriusers-unsubscribe@...
Your use of Yahoo! Groups is subject to
|
Locked
Re: FAQ/Trouble Shooting LOG
I don't have a tons of time myself, but would be willing to give it a
whack...
toggle quoted message
Show quoted text
-----Original Message----- From: Bob Jacobsen [mailto:Bob_Jacobsen@...] Sent: Friday, November 08, 2002 2:18 PM To: jmriusers@... Subject: Re: [jmriusers] FAQ/Trouble Shooting LOG At 1:34 PM -0800 11/6/02, Mark Gurries wrote: Should someone be keeping a FAQ/Trouble shooting Log for each thing we
learn in terms of system setup? Take error messages and translated
them into check actions ect.... I hate to see BOB spend lots of time
in the future addressing common communication problems.
The log should include accessories Q&A such a Locobuffer setup info and
checks. Same with USB to Serial Adapters. You get the ideas.
Personally I do not have the time, but maybe others do. In the end I
hope that this file be included with the install as part of the
documentation.
Just an Idea... And a _very_ good idea. I've put a little of this info onto the web pages, but if somebody wanted to write a section of the manual on troubleshooting, it would help a bunch of people. Unfortunately, I'm having trouble even keeping up with the email, as this late reply attests. There's this blasted day job.... Bob -- -------------- Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957) To unsubscribe from this group, send an email to: jmriusers-unsubscribe@... Your use of Yahoo! Groups is subject to
|
Locked
Re: LocoBuffer/Decoder Pro Problem
I wish he was Bob but Bill's in AZ!
Jon Miller
AT&SF
For me time has stopped in 1941
Digitrax DCC owner, Chief/Zephyr systems
NMRA Life member #2623
Member SFRH&MS
|
Can any of this group that have a Zephyr test the feedback for me. Mine
basically doesn't work. Several calls to Digitrax and their line is I'm the
only one that's unhappy, they have heard nothing about this problem. Also
the line these are only designed for Digitrax products appeared when I
mention the other decoders I am using. Has Digitrax gone this far off the
edge?
However in private conversation with a member of the Digitrax list I
received this;
"So really what you are saying is your DecoderPro is not receiving feedback
when
reading decoder values? I get ZERO feedback to my DT300 when I use that for
programming."
Interesting!
Jon Miller
AT&SF
For me time has stopped in 1941
Digitrax DCC owner, Chief/Zephyr systems
NMRA Life member #2623
Member SFRH&MS
|
Locked
Re: LocoBuffer/Decoder Pro Problem
At 6:40 AM -0700 11/8/02, billroger wrote: And of course I have never been able to program a decoder. You've been incredibly patient through all this. Do you happen to be located in California? If so, maybe I should drop by with some test equipment and try to figure out what's going wrong. I live in Berkeley, and get around most of Northern California for work. And this weekend I'll be in Anaheim, and could free up a couple hours if you're somewhere in the southern part of the state. Bob -- -------------- Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957)
|
The code _requires_ that echo be on. It listens to the incoming messages, including the echo'd ones it transmitted, to figure out the order in which things actually happened on the LocoNet. If you try to run it with echo off, various operations (including programming) will probably hang.
Bob
toggle quoted message
Show quoted text
At 11:20 AM -0800 11/6/02, Peter Ely wrote: And John recommends Echo be on.
..P
-----Original Message-----
From: Robin Becker [mailto:rbgroups@...]
Sent: November 6, 2002 9:38 AM
To: jmriusers@...
Subject: [jmriusers] LocoBuffer jumpers
Someone asked about the locobuffer jumper settings. Here's
the info based
on the schematic John Jabour posted:
JP1 Baud rate
1-2 19200
2-3 57600
JP2 Echo
1-2 off
2-3 on
JP3 Operating Mode
1-2 MS100 compatibiity mode
2-3 LocoBuffer mode
JP4, JP5 Programming
1-2 Normal
2-3 Program
Notes:
1. I think that you need to cycle power after moving the
jumpers before the
changes take effect.
2. JP4 and JP5 should always be 1-2 unless you are
reprogramming the PIC.
Robin Becker
Tucson, AZ
D&RGW Model Railroad Layout
To unsubscribe from this group, send an email to:
jmriusers-unsubscribe@...
Your use of Yahoo! Groups is subject to
To unsubscribe from this group, send an email to:
jmriusers-unsubscribe@...
Your use of Yahoo! Groups is subject to
--
--------------
Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957)
|
Locked
Re: FAQ/Trouble Shooting LOG
At 1:34 PM -0800 11/6/02, Mark Gurries wrote: Should someone be keeping a FAQ/Trouble shooting Log for each thing we
learn in terms of system setup? Take error messages and translated them
into check actions ect.... I hate to see BOB spend lots of time in the
future addressing common communication problems.
The log should include accessories Q&A such a Locobuffer setup info and
checks. Same with USB to Serial Adapters. You get the ideas.
Personally I do not have the time, but maybe others do. In the end I
hope that this file be included with the install as part of the
documentation.
Just an Idea... And a _very_ good idea. I've put a little of this info onto the web pages, but if somebody wanted to write a section of the manual on troubleshooting, it would help a bunch of people. Unfortunately, I'm having trouble even keeping up with the email, as this late reply attests. There's this blasted day job.... Bob -- -------------- Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957)
|
Locked
Re: My 2 hours with decoder pro and Win XP
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)
|
Locked
DecoderPro communications problems & request for info
First, thanks for all the kind words.
There seem to be several problems happening.
1) It appears that certain models of the Keyspan PDA adapter can't handle the LocoBuffer's 57,600 rate. This might be an problem in the program that's interacting with the adapter, but it only seems to happen for some adapters and not others.
The work-around for this is to use the 19,200 rate for the LocoBuffer.
I'd be very interested in knowing whether "hardware flow control" has any impact on this problem. Specifically, does having "no flow control" set make the 57,600 setting work? Does "hardware flow control" work at 19,200?
This problem has been reported twice, both on Macintosh. If anybody uses a USB adapter on Windows or Linux, would you please let me know whether it's working or not at 57,600?
I've updated the LocoNet connection web page with some more info on this.
<
2) Some Windows machines have what appear to be RS232 control lead problems with LocoBuffer & DecoderPro.
The symptom for this is being able to see LocoNet traffic in the monitor via a LocoBuffer, but being unable to send to the LocoNet. This results in programmer timeouts, etc.
Some people have reported being able to bypass the problem with the "no flow control option".
Others have reported that connecting pins on the LocoBuffer will fix this. (See
<>
for details).
Without connections to the DCD and DSR leads, the LocoBuffer isn't really providing a "true RS232" output. But that only seems to effect some PCs. It's not clear whether this is OS-version specific, PC model-specific, or something else. It's possible that the 25-pin to 9-pin cables being used have something to do with it.
I'd very much like to understand this better. In particular, if you've had to bypass a problem like this, could you let me know:
a) What OS version (e.g. Win XP, ME, etc) and computer model
you've got.
b) Whether "no flow control" option worked for you
c) If you fixed it by jumpering the LocoBuffer RS232
connection, had you tried and failed with the "no flow
control option"?
3) There are some problems with NCE systems and USB adapters that I'm still trying to understand. I'll write more about that soon. Please, if you're having trouble getting DecoderPro to communicate with a NCE or Wangrow system, don't suffer in silence. Ask on the list or let me know directly. I've not figured out the pattern on this one yet.
Thanks for your patience, and your help figuring all this out.
--
--------------
Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957)
|
Bob Jacobsen