| |
Ralph Hempel wrote:
> 1. How important is it to have more than one port with DCC
> capabilities. The reason I'm asking is that it "would be
> nice" (tm) to have one output controlling the track and
> another output controlling a pair of wires that does stuff
> like driving discrete motors, lamps, etc.
Yes, it would be nice, plus the two or three unused sensors...
I'm happy enough with the LDCC firmware as a DCC encoder (pleased as punch,
really). But it "would be nice" if it were implemented as a library or patch to
an existing brick OS such as brickOS or pbForth, for the reasons above. I am more
interested in RCXs (and Spybots?) which act as DCC decoders or "clients". Mark
Riley's LACC does this, but its capability is limited. I'd prefer a "minimum set
of functions" for decoding the DCC signal (or LDCC IR Protocol), then I can
"figure out the rest" in my application. ;) In fact, I have started this for LDCC
IR Protocol in leJOS, with mixed success so far.
>
> I know there are issues with bit timing, but I think I can
> get around them if we're willing to accept a slower bit rate.
I'm guessing you mean the RCX may not be fast enough to drive the DCC signal and
other tasks simultaneously. There are also issues with power output, but one can
get around this by using a typical (non-LEGO) DCC booster, I believe. Oh, I see
you address this in 2.:
>
> 2. How important is it to have a "pure LEGO" approach. I'm also
> prototyping a power booseter that will take a battery pack
> or wall-wart output and buffer the motor driver so that we
> don't need to parallel the RCX outputs or worry about burning
> them out.
This would be sweet! How much electronics skill would be needed to build such an
animal? Would it be cheaper/easier to buy one off the shelf?
Most (not all) L-guage fans who are willing to go DCC seem to be willing to slide
a little further still down the slippery slope off the Purism mountain.
>
> 3. The traditional Forth approach is to make the DCC functions as
> general as possible and let the user write the wrappers that he
> needs.
>
> One of the cool things about pbForth is that the train folks that
> are programmers can write these wrappers as needed and then make
> firmware images that they can share. • Cool indeed!
>
> NOTE well that you DON'T need to install a complicated programming
> environment, the compiling, debugging, etc is all done on the
> brick itself! • Very cool, indeed!
>
> 4. How important is the ability to read back the DCC data or to
> set parameters on the controllers? Again, the Forth approach is to
> provide a minimum set of functions and then let the application
> folks figure out the rest.
If you're talking about implementing a DCC controller (i.e. encoder) in pbForth,
then it will have to be able to set parameters, or one wouldn't be able to set
addresses on the DCC decoders. Being able to read them back "would be nice", but
I haven't had a need in the three-odd months I've been toying with DCC.
>
> Just some thoughts to get the discussion going. I'd really like to
> know more about your vision for this system.
Why, my vision is a nnn by nnnn layout of trains; semi-autonomous level crossing
gates, point switches, and signal lights; and fully autonomous LEGO robots
(picture a LegWay dressed as the Stay Puft Marshmallow Man marauding the layout)
networked via DCC and LDCC IRP and directed by a Palm-based LDCC IRP GUI throttle.
Thanks for asking.
>
> NOTE: Thanks to Dave Koudys for lending me a DCC train motor and a
> circle of track to help me develop this stuff!
But you need *two* DCC train motors to make it fun ;)
-Brian
|
|
Message is in Reply To:
2 Messages in This Thread:
  
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
