To LUGNET HomepageTo LUGNET News HomepageTo LUGNET Guide Homepage
 Help on Searching
 
Post new message to lugnet.trainsOpen lugnet.trains in your NNTP NewsreaderTo LUGNET News Traffic PageSign In (Members)
 Trains / 21653
21652  |  21654
Subject: 
RE: Trains, DCC, and pbForth
Newsgroups: 
lugnet.trains, lugnet.robotics.rcx.pbforth
Date: 
Fri, 21 Nov 2003 18:58:20 GMT
Reply-To: 
<rhempel@bmts.com/StopSpammers/>
Viewed: 
6076 times
  
The basic DCC ack is defined as an increase of load on
the track of at least 60ma for 6ms +/- 1ms.  Normally
this happens on a quiet track where all you have powered
is the decoder being programmed at the time.  However, if you
have a bunch or trains on the track, all moving at various
speeds (all using pulse width modulation), the load is going
to be bouncing all over the place and it seems like it would
be difficult to pull the ack signal out of all that noise.
Special headlight effects, like available on the Digitrax
DZ143, could inadvertantly create load patterns that aren't
discernable from an ack.

DOH! Of course. In the fire alarm business, we have a three
state voltage out to the sensors. Usually the Vout is 24V and
the device can respond when the voltage falls to 5 V.

The devices have a power supply that is basically a big cap and
a zener diode. When the line voltage is below the zener cutoff
or is lower than the internal cap voltage, the device draws
no current.

That's how we guarantee no other curent is on the wire pair.

However, there might be other ways, like introducing a
load the varies at a specific frequency and duration (chosen
to not conflict with the type of load you see from a mobile
decoder).  You could use a bandpass filter to pick that
signal out of all the noise.

Yes.

Is there another way we can get lots of sensor inputs to
an RCX, or are we better off just buying a "real"" DCC
controller that can be driven from a PC???

Sorry if LDCCIRP is old news to you, but in reading
your messages it wasn't clear to me if that was the
case or not.

LDCCP is old news to me, but it's good news! I'm trying to promote
pbForth becuase you can program and test stuff interactively.

I've used pbForth to teach kids programming, and adding a fun
thing like a train into the mix just makes it more interesting....

Another way to do it is to add a second DCC channel for things like
sensors. My pbForth does support interleaving DCC messages on
two motor outputs. In other words, send a message on PortA, then
one on PortB, and even PortC for the third one!

Maybe separate motor/sensor buses using DCC are the way to go. That
way the ACK pulses from sensors don't get muddled with motor current?

Ralph



Message is in Reply To:
  Re: Trains, DCC, and pbForth
 
(...) The basic DCC ack is defined as an increase of load on the track of at least 60ma for 6ms +/- 1ms. Normally this happens on a quiet track where all you have powered is the decoder being programmed at the time. However, if you have a bunch or (...) (21 years ago, 21-Nov-03, to lugnet.trains, lugnet.robotics.rcx.pbforth)

16 Messages in This Thread:






Entire Thread on One Page:
Nested:  All | Brief | Compact | Dots
Linear:  All | Brief | Compact
    

Custom Search

©2005 LUGNET. All rights reserved. - hosted by steinbruch.info GbR