Model RailRoad DCC Projects
shanghai_fool
Posts: 149
Has anyone written any objects for DCC decoding? My search has not turned up anything other than the basic DCC driver in OBEX.
Donald
·
Donald
·
Comments
It shouild not be too hard for an experienced programer as the structure is fairly straight forward. I will work on it if no one has already done it. I just hate reinventing the wheel but there is so much more could be done using the propeller as its brain. The shortest bits are ~50us so it should be easily doable, even·in Spin.
The largest commercial decoders operate a maximum of 8 turnouts (switches). A single propeller could operate dozens.
Donald
A year ago I also build my own DCC Booster. I had a command-terminal running on the PC and could send all commands bitwise. Unfortunately it's AVR code because I did not have a propeller that time. But to be honest - using a propeller as command station makes sense, but as decoder I'd never use a propeller. Why would you like to waste so much computing power (and money) for such a simple task?
Where it would make sense is maybe a DCC testing device. Using it's TV or VGA output to monitor what's going on on your DCC lines.
Besides, I had much rather write Spin code.
Donald
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter, E.I.
www.brilldea.com - Prop Blade, LED Painter, RGB LEDs, 3.0" LCD Composite video display, eProto for SunSPOT
www.tdswieter.com
Did you find some documents yet? Otherwise I can have a look if I have some english documentation of DCC.
en.wikipedia.org/wiki/Digital_Command_Control
www.nmra.org/standards/standards.html
www.nmra.org/standards/sandrp/consist.html
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter, E.I.
www.brilldea.com - Prop Blade, LED Painter, RGB LEDs, 3.0" LCD Composite video display, eProto for SunSPOT
www.tdswieter.com
I have the "1"'s and "0"'s decoded so I just need to combine them into bytes and packets. Then I will try to see the methods used.
·
"Sometimes the act of observing changes that which is being observed."
While taking a TV break, I think I am not seeing what is really there. Spin, especially when using the terminal, may not have enough time to properly decode the data.
I will continue tomorrow.
Donald
·
Don't have the system here at work, which is the only reason not posting it straight away.
Basic components:
LMD18200 H-bridge, driven by a propeller (prototype used a Propeller Demo board; final version uses a custom PCB)
output: serial 4x20 lcd (from moderndesign.com)
input: PS2 keyboard
power: being supplied by the old train power supply, with the throttle set so that output is at 14v
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
---
Jo
Dave
After offloading the packet reading to another cog, I am able to decipher the packets. The basic reading object in spin has plenty of time to decode the bits and transfer the bytes to a buffer.
I have 4+ ms to decipher the packet. So far I have decoded the basic packet and some of the extended packets. I am not seeing all the data I expected, however.
I can read the address, speed and direction but I fail to see the proper functions operate. If anyone has a DCC controlled layout and willing to assist, I will post the code I have so far.
Donald
Works great.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter, E.I.
www.brilldea.com - Prop Blade, LED Painter, RGB LEDs, 3.0" LCD Composite video display, eProto for SunSPOT
www.tdswieter.com
I am using a couple of pins to sync scope and test timing of procedures. These will be removed later.
There are 2 different type os turnout mechanisms used. One is the pulse type which just uses a solenoid and a momentary contact. The Tortoise uses a 12 v bipolar continuous output. The Prop output can be made to use either with different hardware.
I want to add writing to the upper eeprom to save the last position for next power up. There is so much more I could do with this but need to wait for ideas.
Attached is "quick & dirty" code. I will clean up later. I am open to suggestions and ideas about what else can be done now that we have the data. I should add decoding of the other functions but they have more to do with CV programming and I don't have a programming station·so no way to test it.
Have Fun
Donald
Basic Decode object:
{{DCC Test Program This program uses the packet Object to get the data from the booster(rails). It also uses the PC_Interface to display the data I use a 6N137 optoisolator with the LED connected to the rails through a 1.2k resistor. The output is pulled up to 5v through a 33k resistor and connected to port 0 through a 2.7k resistor. I use port 1 and 2 as troubleshooting pins for development. Port 1 is high while waiting for preamble. It is useful for triggering scope. Port 2 is taken high while processing the data. It was to confirm how long the process was taking. }} con _clkmode = xtal1+pll16x _xinfreq = 5_000_000 var long temp long pnum long eaddr 'extended address byte addr byte cmd byte index byte buffer[noparse][[/noparse]30] obj text : "PC_Interface" rd: "packet" pub main | i,j,each text.start(31,30) text.out(0) dira[noparse][[/noparse]2] := 1 outa[noparse][[/noparse]2] := 0 text.str(string("DCC Test Program")) waitcnt(cnt + 80_000_000) text.out(0) text.str(string("Loco SPD L4321 8765 ")) pnum := 0 index := 0 'clear buffer repeat 30 buffer[noparse][[/noparse]index] := 0 temp := rd.start(@pnum,@index,@buffer) 'text.dec(temp) setpos(1,1) repeat while pnum == 0 repeat waitpeq(2,2,0) outa[noparse][[/noparse]2] := 1 addr := buffer[noparse][[/noparse]0] cmd := buffer[noparse][[/noparse]1] if addr < 128 setpos(0,addr) text.dec(addr) setpos(4,addr) CASE cmd & 224 %01000000 : 'Reverse text.str(string("R ")) setpos(6,addr) temp := (cmd & 15) << 1 temp := temp + ((cmd >>4) & 1) text.dec(temp) text.out(" ") %01100000 : 'Forward text.str(string("F ")) setpos(6,addr) temp := (cmd & 15) << 1 temp := temp + ((cmd >>4) & 1) text.dec(temp) text.out(" ") %10000000 : '100DDDDD Function Group 1 setpos(9,addr) text.bin(cmd,5) %10100000 : '101SDDDD Function Grooup 2 if buffer[noparse][[/noparse]1] & 16 'Functions 5-8 setpos(15,addr) text.bin(cmd,4) else 'Functions 9-12 setpos(20,addr) text.bin(cmd,4) else if addr <> 255 ' this gets rid of nop's ' Basic Accessory Decoder '{preamble} 0 10AAAAAA 0 1AAACDDD 0 EEEEEEEE 1 -- What the NMRA says ' 100AAAAA 1111AAAC What I see with MiniDCC eaddr := ((addr & %00011111) <<2)+ ((cmd & %00000110)>>1) if eaddr <> 0 setpos(0,11) text.dec(eaddr-3) text.out(" ") text.out((cmd &1)+48) outa[noparse][[/noparse]2] := 0 waitpeq(0,2,0) ' wait for next packet PRI setpos(px, py) text.out(10) text.out(px) text.out(11) text.out(py)Get packet data object:
{ This object continually gets the data from the rails thru optoisolator and transfers to main program. } VAR long Stack[noparse][[/noparse]20] 'Stack space for new cog byte Cog 'Hold ID of cog in use, if any byte data byte bit PUB Start(pnum,index,buffer): Success {{Start new servo input process. Return True if successful.}} Stop Success := (Cog := cognew(Measure(pnum,index,buffer), @Stack) + 1) PUB Stop {{Stop toggling process, if any.}} if Cog cogstop(Cog~ - 1) PUB Active: YesNo {{Return TRUE if process is active, FALSE otherwise.}} YesNo := Cog > 0 PUB Measure (pnum,index,buffer) | j,k, idx dira[noparse][[/noparse]1] := 1 outa[noparse][[/noparse]1] := 0 repeat idx := 0 outa[noparse][[/noparse]1] := 1 getpre outa[noparse][[/noparse]1] := 0 repeat while bit > 70 data := 0 repeat 8 'waitpeq (0,1,0) data := data << 1 waitpeq (1,1,0) j := cnt waitpeq (0,1,0) k := cnt bit := ((k - j) / 80) if bit < 70 data++ else BYTE[noparse][[/noparse]buffer][noparse][[/noparse]idx++] := data waitpeq (1,1,0) j := cnt waitpeq (0,1,0) k := cnt bit := ((k - j) / 80) BYTE[noparse][[/noparse]index] := idx LONG[noparse][[/noparse]pnum]++ pri getpre | i, j ,k, l 'get preamble i := 10 repeat while i waitpeq (0,1,0) waitpeq (1,1,0) j := cnt waitpeq (0,1,0) k := cnt bit := ((k - j) / 80) if bit < 70 i-- else i := 10 'not enough, start over. ' ok got at least 10 1's ' now look for '0' repeat while bit < 70 waitpeq (1,1,0) j := cnt waitpeq (0,1,0) k := cnt bit := ((k - j) / 80)▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter, E.I.
www.brilldea.com - Prop Blade, LED Painter, RGB LEDs, 3.0" LCD Composite video display, eProto for SunSPOT
www.tdswieter.com
I am interested in LocoNet but I have to come up with a controller that will do what I want. I can't really afford the Digitrax controllers as the shipping is prohibitive and there are features that they don't have. Beside, what better way to get something going on the Propeller. I have gained a lot of knowledge about the DCC protocol with this project but I have lots more to learn before trying to design the controller. Both the Bachmann and the MiniDCC are too limited and the commercial units are too expensive. I think the Propeller would make a fantastic controller and it could certainly talk with LocoNet or any other proprietary network.
It was kind of frustrating doing the decoder as I only have the 2 controllers and they handle turnouts completely different. The MiniDCC did not seem to follow the NMRA RP as I understand it. Thats why it took me so long. Also, I had to learn how to start and talk to another cog.
This is a very inexpensive solution as the going prices of $50(US) for 8 point driver if I could get them here. This one for 24 points should cost less than $50. I probably will not do a PC layout for only one unit. I have a protoboard laying here that doesn't have an application and size is not a concern in this instance.
I have an idea for a throttle but I will wait until I test it out before going public.
Donald
Been on hold a bit but so far I have completed (untested) DCC & S88 drivers and am working on the control bus. UI will be next.
Will post more details if requested [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
-Alec
Velden in N scale
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter, E.I.
www.brilldea.com - Prop Blade, LED Painter, RGB LEDs, 3.0" LCD Composite video display, eProto for SunSPOT
www.tdswieter.com
Again, it sounds like several people have worked on this, but only Shanghai Fool has done some posting of the details. It would help everyone here (including those that do not post and just read the forums) to learn from posting more DCC examples. Perhaps together we can create some robust drivers and place them in the object exchange.
Basil - I am interested in learning more about S88, do you have links? Why did you chose that? From what I understand Shanghai Fool was having trouble choosing a particular DCC system because of lack of turnout control or quantity of control. What have you found in your experience?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter, E.I.
www.brilldea.com - Prop Blade, LED Painter, RGB LEDs, 3.0" LCD Composite video display, eProto for SunSPOT
www.tdswieter.com
My code is on another PC which is at home at the moment, but Ill post it when I get a moment [noparse]:)[/noparse]
S88 is straight forward as its effectively a giant shift register.
Electrically speaking, each feedback unit has a 4044 latch and 4014 shift register and all the feedback units are cascaded. So on each CLK pulse, the bits are shifted one by one towards the Prop, making their way through the cascading registers, and after all bits have been collected, the latches are reset
Heres a good overview
and electrical...
It offers no error correction whatsoever but because its so easy to implement and the update frequency can be quite high, any errors are smoothed over anyway.
Only changes in state are recorded which can be performed with a simple XOR.
I chose it because its easy and cheap to make the decoder, and due to its simplicity all datacollection and management can be performed in a single cog written in spin.
ADDITION:
Turnouts can each be connected to one of the register's bits so their state can be read.
The DCC command to move the turnout will stay on the queue until the state read by the S88 bus matches the state of the turnout stores in HUB memory.
Hope that makes sense
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
-Alec
Velden in N scale
Post Edited (Basil) : 4/24/2009 2:12:34 AM GMT
Note: I use looooong variable names :P
An explanation of the different routines...
PUB main: This is the startup COG and will also be the user interface once everything is up and running.
PRI Xnet_manager: This manages communication with the Xpressnet devices and also processes all commands received and acts on them. INCOMPLETE. This is what I was working on last, just trying to streamline things rather than using a ton of if...thens.
PRI DCC_Manager: Manages DCC queue and prioritise commands. I think its complete but probably full of errors because I had trouble wrapping my head around things at the time it was written
PRI ID_Get_Ptr: Gets the pointer to a loco in the database based on loco id.
PRI DCC_Send_cmd: Processes a DCC command ready for transmitting. Pretty much just determines how many bytes to send.
PRI DCC_Loop: Does the dirty work. Outputs DCC command.
PRI S88_Manager: Does all the S88 stuff and updates 2 arrays in HUB memory, Current status and changes since last update.
PRI Wait_us: Ill let you figure this one out...
Hope it helps! This was all written without testing as I have no prop. I also have never used DCC before so its all based around the NMRA documents for DCC, Lenz documents for Xpressnet and stuff on the web for S88.
Oh, and its all written in BST [noparse]:D[/noparse]
Feel free to ask questions!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
-Alec
Velden in N scale