|
> > I will be adding DCC capabilities soon through - so some of these train-heads
> > can do some interesting programming.
>
>
> Hmmm. I was seriously considering writing a leJOS package to support the LDCC IR
> Protocol. (Here's why: http://news.lugnet.com/trains/?n=20951 ) What capabilities
> were you going to add? Depending on your timeline, you might convince me to try
> FORTH.
OK, I've looked at your wish list and have the following comments
with respect to how I see the pbForth implementation of DCC.
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.
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.
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.
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.
NOTE well that you DON'T need to install a complicated programming
environment, the compiling, debugging, etc is all done on the
brick itself!
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.
Just some thoughts to get the discussion going. I'd really like to
know more about your vision for this system.
NOTE: Thanks to Dave Koudys for lending me a DCC train motor and a
circle of track to help me develop this stuff!
Ralph
--------------------------------------------------------------------
Check out pbFORTH for LEGO Mindstorms at:
<http://www.hempeldesigngroup.com/lego/pbForth>
Buy "Extreme Mindstorms: an Advanced Guide to Lego Mindstorms"
<http://www.amazon.com/exec/obidos/ASIN/1893115844/hempeldesigngrou>
--------------------------------------------------------------------
Reply to: rhempel at bmts dot com
--------------------------------------------------------------------
|
|
|
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
|
|
|