Click to See Complete Forum and Search --> : Digital train control / software / electronics


JVene
July 12th, 2007, 04:01 PM
Here's something I've not found another forum for...

I'm asking about the feasibility of an idea to use the audio card of a PC to generate the control signal for a DCC model train layout, passing that through an audio amplifier. It's a project aimed at a little father/son time (a 6 year old), while saving money on the control electronics.

If you're familiar with both electronics (not expert, just familiar) and programming, especially audio, you may find this interesting for discussion - especially if you're a parent. I'm asking for advice/suggestions, but it's also an interesting discussion topic for programmers just on theory.

Anyone around here have any knowledge/experience in software and technical work on DCC model train controls? (For those interested but not familiar, that's digital control for trains, a protocol for transmitting data over the power supplied to model train tracks).

The link isn't handy, but easy to find, from the NMRA (model railroad association) describing the technical details of DCC protocols, but it's fairly straight forward.

My son, 6, got an electric HO scale model train (Thomas the Tank Engine - a child's storybook character), a couple of cars and enough track for an oval. He's hooked, now, and wants the 'other' engines in the series. In the stories, each engine has a name, a character and a particular form (they all have faces with moving eyes). Its a great thing for some father/son time, and I realized that two engines on one track means digital control.

We got the first train setup, but I had no power supply. I cobbled one together with spare parts. A bipolar transformer, diodes, a few resistors, capacitors and a chip based operational 50 watt power amplifier (for those not familiar, operation amplifiers are a particular design with two inputs, a + and - input where the - input inverts the phase of the signal, and the output is the difference between these two inputs; typically used in audio applications).

The chip based amplifier can produce DC, handles a few amps current, gives me short circuit/over current/thermal protection. Using a simple volume control I can bias the voltage output of the amp, giving a speed control. Since it's bipolar, it can do forward and reverse.

But, that's a DC voltage swing on the entire track. Two engines on one track are a real drag that way (and, my son's likely to want, ask for, and end up getting a few more engines :) - ok, maybe I want a couple more, too).

So, I've found some DCC decoders for about $18 shipped. These are smaller than postage stamps, so they fit inside the engines. They respond to digital commands sent over the track so engines can be controlled independently. The track is powered by AC, which itself is modulated to include the data. The decoders can be programmed for an "ID" number, a single numeric value identifying each device (some devices are track switches, lights, horns, smoke, etc).

Here's were my inquiry comes in (in a moment).

What I learned is this:

The data is transmitted along with the power. The decoders actually control the engine speed independent of the power supply. Typical AC (house power) is 60hz (changes polarity in sine waves at 60 times per second). This AC track power is switched between about 9.1Khz and 4.6Khz in square waves.

The decoders interpret a data bit of 1 if the width of the positive and negative voltage swing lasts about 54 microseconds, which corresponds to a frequency in the area of 9Khz. If the pulse width lasts over 100 microseconds, that is interpreted as a data bit of 0. The spec states a zero can be elongated much longer.

Now, in the product line that does this stuff, power boosters (which simply amplify the digital signal to track power levels, and come in power ranges from 3.5 amps to over 10 amps at +- 16v) are about $100 to $500. The digital command module is another $100 to $250. That's not in the price range of a toy!

There are decoders for complex engines, with sound and other effects, that cost $100 or more. However, simple 1 amp speed decoders can be purchased for $18 or less. These seem a good fit for the toy Thomas engine (and the other engine characters).

Here's my design plan, and the actual area of my inquiry.

I intend to use the little audio power amp I've already built to power the DC version of the train to provide power (taking the position of the power booster). I plan to use the audio card to provide the digital output signal, which will drive the amp just as if it were sending out audio. Between the computer and the amplifier I probably need to add a small signal buffer, which will adapt the output of the computer (basically square wave audio) to the power amplifier, to adjust the track voltage to swing + and - at 16volts.

Thinking about audio as a digital output, I realize that 44.1Khz doesn't match well with a pulse duration of 54 microseconds. 1 sample at full amplitude is around 22 microseconds, two would be 44 and so 3 samples, lasting 66 microseconds, is too long. Switching to about 37 Khz sample rate, however, makes two samples just about perfectly align to a pulse width of 54 microseconds, making a digital 1 for the DCC standard.

4 samples make a zero.

So, I'm envisioning an application, for which I will choose C++ (my own favorite for over 15 years) that generates this audio control output according to a dialog based interface of sliders representing train speed and direction for each of the engines we end up deploying on the track.

The NMRA specs describe the format of the data rather explicitly, including modes for 'programming' the decoders (basically setting their engine ID), and the various commands for stopping, reversing, setting speed, etc). The standard indicates that a command is sent repeatedly, and decoders ignore the repetitions, but repetitions are needed to overcome track noise that corrupts the data stream occasionally. This also has the effect of keeping the power running as AC somewhere in the 4Khz to 9 Khz range.

Like IP, each 'message' includes the destination ID, which is how engines are addressed independently - messages are interleaved, and it seems the overall rate at which messages are dispatched are in the range of 50 to 200 messages per second, depending on the message length and format.

The spec also describes that slew rate limitations of the decoders. They expect at least 2 volts per microsecond, though the spec dictates the power booster/digital command must supply at least 2.5 volts per microsecond. The power chip I'm using provides 12 volts per microsecond. Pulse durations can vary some 10% or more, so timing is all that critical (I think the 1 pulse can range from about 52 microseconds to nearly 60 microseconds).

The power booster I built cost me about $15 in parts, plus an hour of fabrication which my son really enjoyed 'helping' with. A buffer would require a regulator, which I have the parts for, adding another $3 or $4 overall, plus some scrap cable/connectors for the audio interface. An old P2-400 with a sound card should suffice as the train controller, with an old 15inch monitor (all spare parts stuff).

I intend to set output from the audio card to 8 bit audio at about 18.5 Khz sample rate (where 1 sample is around 54 microseconds). That would make demand on the P2-400 minimal.

For other technical reasons I do intend stereo output and may create a second power booster (for something called track reversal loop, where a track loops back onto itself, requiring a reverse of polarity, or at least a synchronization of phase, where an engine transfers back onto track in the reverse direction). This may involve a few proximity sensors, so I can tell when an engine has entered into a reversal loop section. While there, the phase of the power signal must be inverted while the engine is running, which I plan to do by elongating a zero until phase is matched with the destination track, powered by the second audio channel/power booster.

Track reversal electronic devices cost about $45, and handle only one reverse loop. I think I can create 3 'sensors' (one at each entrance into the reversal section, one inside the reversal section) for about $1.50 each, using old cassette tape playback heads (or just loops of small gauge wire around a small iron core - to sense the 'noise' of the motor as it passes over the sensor under the track) and a couple of operational amplifiers to create a signal comparator that can generate a logic 1 which I can sense on one of the 8 lines of the parallel port. For our layout I don't suspect I'd have room for any more than two reversal loops, so two loop sections would be possible, software would otherwise handle the transition using stereo audio output.

If that's not quite clear, here's a clearer description of the problem.

For a short timeslice (say 10 microseconds, where we can consider the polarity at that moment) a train might be moving on a loop that joins the same track that entered the loop (like the loop of a lasso). If the track were really connected this way, the + polarity would end up connecting to the - polarity, creating a short.

So, the loop is cut into 3 sections. This looks, then, like a Y, where the two top legs of the Y are joined by a curve, but not electrically connected.

When the engine moves from part of the Y to the curve, the engine will complete a circuit connection, with it's wheels, between the Y and the curve - but only on one side of the Y at a time. One side as the engine enters the curve, and the other as it leaves.

The entire Y is a single electrical path (one rail +, the other rail -), and part of the 'main' track power - sharing the main track's polarity.

Some people have to rethink that to realize there really is a problem. It ends up that what is a 'right' rail physically connects to the 'left' rail when the curve ends up connecting to the base of the Y, creating a short. You have to envision this shape with two rails and follow the path from one side to the other to realize they would cross-connect.

Thus, the electrical isolation of the curve atop this Y.

At each of the two upper legs of the Y, and proximity sensor would inform the computer that the engine is about to enter the curve, and start powering it (from the second audio channel) in sync with THAT SIDE'S polarity direction relative to the engine's orientation. When the engine jumps the electrical isolation, it will receive power in sync with the polarity of the main track from that viewpoint.

A second proximity sensor will inform the computer when the engine is inside the curve section, meaning it's electrically isolated from the main track. At this time, the second audio channel, exclusively powering the curve section, would extend the zero length of a message until the main track switches phase (it's AC remember), bringing the curve and the main track in phase with respect to the polarity as viewed from the engine's orientation when it re-enters the Y (in what's now the reverse direction).

When the third sensor fires, it means the engine has left, is no longer on the curve section, and that can be powered down (or made available for another engine to enter).

If any other reverse section receives a signal of an engine entering a reverse loop while all this is happening, I'd probably have to issue a 'stop all engines' command and let either my son (or me) give one engine the go ahead manually. If I had full transponders, I could have the computer figure out which engine is there first, and hold the other(s), but that's just too much, especially since the odds are probably low.

Ok, finally, the nature of my inquiry and posting.

Does anyone have enough familiarity with DCC to advise if my plan makes any sense? Is the square wave DCC signal beyond the range of an audio power amplifier (I'm of the opinion it is within the capabilities, given some slight wave shaping care against square wave transitions creating harmonic distortions).

Anyone find the project interesting enough for me to continue the thread as I proceed to create the thing? I expect to get rolling in a month or less.

If you have kids and are curious about the Thomas engines (the 'standard' Thomas toys are wooden trains on wooden tracks), Bachmann makes the engines and can be found through a google search. Although an electric set, with track, can cost around $80 or so, it compares reasonable with the cost of wooden sets ($20 for a wooden engine, non-powered, similar costs for track). The DCC conversion is an electronic project (soldering iron, wire, disassembly - there's a web page of instructions, search Thomas DCC and you'll find it).

Track reversals aren't typically required - you can layout track without them. We have a 3' x 4' train table (intended for the wooden trains), but it's just a little too small for the HO track, even for a simple oval - but a slightly larger plywood sheet on top of the table gives just enough extra space to make it fit. I've found Atlas, the track manufacturer, has a free track layout software (not great, but adequate) - and I've designed a layout including a helix spiral elevator to a second table level 16 inches above the main table, two runs of track at 22" radius turns (with a 19" interior) made with flex track (shaped track - the standard is 18" radius) - and a second level with another layout including a reverse loop.

My son has been making 'city scapes' for years (started by shaping straws into light poles before he was 2), so we're 'decorating' the layout with traffic lights (playdo and LED's), signals and bridge lights (white LED's), street lights (which he now makes out of 6 gauge solid core copper wire) and other 'hand crafted' accessories, including bridges, stations, etc.

PeejAvery
July 12th, 2007, 04:25 PM
So finally after reading all that, I came to your question. I would suggest putting your questions at the top that way people won't be discouraged and not respond to such an enormous post.

JVene
July 12th, 2007, 05:00 PM
Thanks,

The general question, about DCC control of trains, is in the 4th sentence.

I don't see how I can ask if an idea sounds plausible without first showing the idea, but it's true that I'm generally quite verbose.

dglienna
July 12th, 2007, 06:11 PM
Sounds like your site, but, I'd think you'd be better of with some kind of microprocessor that does a/d d/a conversion.

Also, is this something you can BUY for the trains, or is it all CUSTOM?

JVene
July 12th, 2007, 06:48 PM
My thinking is to rely on the fact that the sound card is a D/A converter, with it's own very simple DSP (a special purpose computer clocked at around 25Mhz). The computer I intend to use is spare parts.

They do make and sell this stuff, but 'real' hobbyists will pay upwards of $150 to $250 for an engine and perhaps $1,000 on track alone (they'll have a living room sized area devoted to it, too). For those hobbyists, $250 or more on controller electronics is nothing.

For my son and his $28 Thomas engine, and maybe $75 in track (some of which is donated from friend's old stock), it doesn't make sense. I need to keep the costs low, so putting electronics and programming knowledge to work in that direction seems reasonable.

dglienna
July 14th, 2007, 04:47 PM
My cousin read this thread, and is an avaid modeler.

He says that DAC's cost about $300, but if you could get it working, it'd be promising.

Have you looked into MIDI format? It may work well for that.

JVene
July 15th, 2007, 12:43 PM
I'm interested in any curious audience for this thread, but your cousin is precisely of the kind I had hoped to engage. I haven't received much response from train oriented forums.

Midi (the digital control I'm assuming, not audio output as the result of midi) would have worked well for train control if the industry had considered it early on, but alas the standard is cast as it is. There's considerable similarity in the data format concept - a simple packet of ID/Value, but DCC does include some error checking, which I don't think MIDI did.

I've ordered track and two decoders, started a skeletal application in C++ (have the sound/control signals code, simple UI), now I'm tinkering with electronics to get audio/signal output to generate a balanced, regulated 16V + - output.

I should have the decoders in a week or so, and a second engine by then, too. I'll test & program the decoders 'in breadboard' first before I take the time to install them into the trains.

As I spec all this out it appears I could package a DCC booster with enough power for up to 4 small HO engines (or 3 slightly heavier ones) with the software for a manufacturing cost of about $30-$35, putting retail at around $75 or so - assuming the consumer has a PC to use for the control.

Then, too, just for DIY types - a set of plans (the electronics are actually very simple), instructions and the software might go over well enough with some (like me).

It makes for some great father/son time - better than you can get with video games in the age group 6-9.

TheCPUWizard
July 15th, 2007, 06:17 PM
JVene,

Bin very swamped, and just catching up here on CG. I am rather interested in this project as I do run a DCC based layout. Currently using commercial controller packs, but a PC based solution would provide better integrtion with the other automated aspects of my system.

Send my a PM with and e-mail, and we can discuss further. Of course any "progress" will be posted back here, so other may just find it.... ;)

GremlinSA
July 16th, 2007, 03:16 PM
Reading through your post theres a few things that i have to dissagree with some of your logic....

The track is powered by AC, which itself is modulated to include the data.
-------
I do intend stereo output and may create a second power booster (for something called track reversal loop, where a track loops back onto itself, requiring a reverse of polarity, or at least a synchronization of phase, where an engine transfers back onto track in the reverse direction). This may involve a few proximity sensors, so I can tell when an engine has entered into a reversal loop section. While there, the phase of the power signal must be inverted while the engine is running, which I plan to do by elongating a zero until phase is matched with the destination track, powered by the second audio channel/power booster. If you were using DC track's then you'd need all the track reversal gear... However with using a AC track, Irrespective of witch way the Engine is on the tracks, foward is foward... All you need for reversal is a small dead zone on the tracks, where the engine contacts to the track dont short them out

Something like this
http://i141.photobucket.com/albums/r78/Gremlinsa/other/DeadZone.jpg
Obviosly you have to ensure that the modulated data is either on both track lines, or picking up from both lines. ( Done in most DCC systems..)

Phase shifting is not realy needed.....

Here is a simple Block Diagram of what you need in each engine....
http://i141.photobucket.com/albums/r78/Gremlinsa/other/Controler.jpg

A site worth the visit and prototyped DCC is Mark Csele's Train Set (http://technology.niagarac.on.ca/staff/mcsele/dcc.htm), with full schematics and programming....

Gremmy.....

JVene
July 16th, 2007, 07:54 PM
Phase shifting is not realy needed.....



I don't think this is right, but double check me here.

If there's a dead zone, the engine would stop. The decoders don't have enough size to host capacitors with enough storage to propel the train forward even a slight amount. Each engine is a different length, and most of the drive wheels on each side are electrical parallel, meaning that even if the gap were small enough that the engine would straddle the dead zone (and it would have to be or the engine would 'leave' power), with one wheel in one section, and the other wheel still on the previous section, the two sections of track will be connected through the wheels of the engine.

When that interface happens, the + phase of one section will be electrically connected to the - phase of the second section, connecting through the engine, which, given the overall resistance due to slider/wheel/track interface contact winds up being anything from .1 ohms (nearly ideal/clean contacts) to about 6 ohms - making for a fairly high current drain. The net voltage difference between the + and - potentials would still reach the train, if they were not in perfect balance. If they're both very close to 16 volts (which they will be), the net power reaching the engine would be zero, or very close to zero volts, while the momentary power drain on the booster would reach maximum, probably shutting the power down due to over-current protection circuitry (or at least I'd hope so - sparks & smoke otherwise). Even if the booster remained on, I predict the engine would stall, since the net power input would be near zero volts, 'locking' that short into position until someone reached over and move the engine manually.

It's true that the direction of the engine won't be affected by the phase shift or polarity shift in an AC design. It's about what happens when the engine crosses that junction that seems to me the problem for reversal loops.

To me the solution seemed a phase alignment while inside an isolated track section. I suppose, too, it would be fine just to flip the polarity of the track during an elongated zero cycle - not much different from a programming standpoint.

Am I missing something here?

GremlinSA
July 17th, 2007, 03:27 AM
Ahh.. open discution on the topic .. (I Love these) (BTW. I'm not knocking your logic .. I'm discussing it )

Try one simple experiment.. Run an engine at +- half speed and kill the power.. (best done with a break in the track) , and see how far the inertia caries it foward.. My personal experiance with train sets (1' track width) is it continues about 1 engine length, also most of my engines had the contacts set with one on the front left wheel and the other on the rear right (obviously i have little idea of Thomas engine layout).

I never got round to putting DCC on it although i played with a few ideas, before i put the set in storage. I did play with using multiple supplies for long tracks, using small breaks in the track and filling the gap with some pratly.. My gaps were never more than about 3mm long but were filled so that the wheel runs smoothly over it..

DCC recievers also will not kill the motor as soon as it stops recieving commands, but rather wait a specified time, +- 1 sec, then kill.. In terms of power for the motor a 1000 - 2200 uf cap on the power(after the rectifier) will supply enough charge to carry the motor for at least .25 sec at full speed and runs down within about .5 - .7 sec.. so now you can carry the engine about 2 full lengths (at half speed)

With engines that have both power conectors on the front and back, small elastics are available to place on the wheels (either diagonally opposite or on the front) to isolate them. (I ended up using my braces elastics for this). Or even since the engine will be opened up to install/ Program the DCC, disconection of the second set can be done..

A third option, witch may give better results is to drop in a few diodes to electrically isolate the front and rear wheels from each other too..
http://i141.photobucket.com/albums/r78/Gremlinsa/other/WheelSetup.jpg
Looking at this option may even simplify your DCC design.. As long as no wheel can stradle the break in the track .. (reason for filler) there should never be any power loss to the engine.. hence it could even stop over the 'Dead zone' (one wheel on ethier side) and be started up again..

Also using 8 diodes for full wave rectification will be better, and will result in more power available for the motor..

Then i sat thinking about your PC driver device.. Why not use the serial port.. with baud rate of 57600 you got a higher resolution than with the sound card at 44000,and a lower latency... And at 19200 you get about the resolution you need for the DCC decoder..(actual needed baud would be 18200)

This in turn keeps the signals all in digital and makes it easier to send data to any device on the DCC network.. and depending on your protocal devices can be sent instructions with ~4 bytes on the com port, using a bit of bit code..

Example..
A 1 bit is long high, long low and a 0 bit is short high, short low..
now we break it into serial data.. a 1 bit would be '1100' and a 0 bit whould be '10'..

to send a data packet to device '1' (Bits=001) instruction Foward 1/2 speed (bits=10111) the serial data whould look like
10101100110010110011001100

and in its byte form ..
1010 1100 - 1100 1011 - 0011 0011 - 00.. .....
&HAC CB 33 0.

Also note that the serial port setting whould be set to 8,N,0.. (8 bit, No stop bit, 0 Parity bit)
now to allow the system to continue we simply fill the area with '0' Bit data... or (101010) so we now get &HAC CB 33 2A..

If theres no data to transmit we keep pumping &HAA to the serial port to keep the tracks alive...NOTE: Serial data on the line is reversed.. a 1 bit of data is line held low, and a 0 bit is line held high..

As a bonus, Serial ports are TTL circuit compatible.. So your circuit design for the DCC Modulator is now a Buffer chip (2 input Nand gates - 74LS00), two transistors, and 4 Fet's..

Taking the Circuit a little further, we could couple the RTS & CTS lines on the serial port to a 555 timer so that when no serial data is sent the 555 timer keeps a pulse on the lines to keep them alive.. meaning the serial port is only used to send data, and lifts a load off the system..

If you could detail the DCC decoders (chip number, etc) that you got i could posibly draw up some small scematics to assist you in circuit design...

Gremmy....

GremlinSA
July 17th, 2007, 09:48 AM
I had a little time on my hands and put this schematic together..
http://i141.photobucket.com/albums/r78/Gremlinsa/other/Schematic.jpg
Showing the simplicity of my proposed method...

and the board for this design would look something like this..
http://i141.photobucket.com/albums/r78/Gremlinsa/other/Board.jpg

Looking at it now i see that i forgot the biasing resistors for the transistors, but theres still lots of space for them on the board...

and the cost ~ $10...

Gremmy...

JVene
July 17th, 2007, 03:31 PM
Ahh.. open discution on the topic .. (I Love these)


I was long ago convinced of the wisdom from Socrates and Plato on the subject of open discussion. Though I’m not found of the ‘Socratic Method’ in teaching, except perhaps in the higher philosophies or perhaps law, there is no better way to stop being a fool than to listen to alternative or opposing ideas, just in case new materials appears from the discussion which changes perception, conclusion or foundation.

Nice schematic work – what software are you using for that?

I had not considered using diodes on the wheel brushes to avoid the problem of the engine connecting two opposing sections of track. I see how that could work.

I’ll have to conduct some experiment on that, but I know it’s tough to accomplish on this little Bachmann Thomas engine. The design uses 3 drive wheels, all three picking up power. They use a thin copper (nearly foil) shim to fashion 3 brushes for the wheels, so physically it’s one piece on each side. That makes it difficult to electrically isolate – I’d have to significantly modify that to create an isolated pickup, and there’s not much room to work with as the engine is small (not quite 3 inches long, about half the length of most HO engines). Other ‘characters’ in the set are longer, but several are about this size. There’s just enough room for a DH123 decoder (and many other simple decoders are about the same size as the DH123 as reasonable alternatives, 1amp motor/speed control and 2 125 ma feature controls). With the decoder installed there’s only enough physical space for caps in the range of 5 to 10 uf at 16 or 25 volts. ‘Standard’ HO engines would certainly have enough room for 500 or 1000uf caps, but not this tiny thing.

I checked with a track to track section to see how long the engine might coast on it’s own with power interruption – it continues for barely 1 mm (about 1/16th of a wheel rotation is all it gets). This is probably because most HO engines have a flywheel motor design (and are heavier). This thing has what someone called an ‘open frame’ motor – it does take up about 80% of the interior of the engine, but has nothing to give it inertia, hence it doesn’t react like most HO engines. It appears most of the characters in the Bachmann ‘Thomas’ series have the same motor design concept, probably to accommodate the small engine dimensions of these characters. A few of the engine characters have ‘tenders’ which are otherwise empty, opening possibilities, but Thomas and a couple of the other characters are referred to as ‘switch engines’ (I think that’s the name) – I think it references a kind of small engine used for short runs or moving cars inside the train yard in preparation for ‘real’ engines, so their coal supply is held within the engine, and there’s no tender to hold additional electronics.

When I consider the amount of effort required for the physical modification to the Bachmann engine in order to install diodes as you suggest, then compare that to the efforts required to create a track reversal section, I lean toward the track reversal primarily because of the nature of the shims and the potential that I could end up unable to that to work. I see how your design point would work – the diodes would definitely obviate the problem of shorting the opposing track joint and simplify the issue in track layout, as well as avoiding the need for sensors to discover when the train enters the reversal section. When I consider my strengths and weaknesses for this kind of modification to the engine vs. a track reversal concept, I feel the track reversal works in my stronger areas of expertise, but the modification of that shim plays against my weakness (tools for the work, experience with that kind of mechanical/physical alteration). Still, you got me thinking because I had not considered it a possibility, and I can see that with other more standard engines your concept is quite applicable.

Your idea to use the serial port for data output has good merit, too. It does ride right on the margin of the spec, and that concerns me a little. At 19200 or 38400, the pulse width created is just a hint over 52 usec. In the DCC spec at http://www.nmra.org/standards/DCC/standards_rps/S-91-2004-07.pdf, the duration of a 1 is supposed to be between 55 and 61 usec, though they do state that decoders are supposed to accept a pulse width of 52 usec. The difference between the requirement that a command station provide no less than 55 usec, and the decoder accepting is little as 52 usec is taken up by the slew rate requirements of the power booster. They require 2.5 volts per usec slew rate, which isn’t difficult to provide, and would ‘trim’ even a 55 usec command output to as short as 50 usec (when the swing moves from + to – the + swing is shortened both on the leading and trailing edges, probably asymmetrically). The power chip I’m using now provides 12 volts per usec, but even that would trim a 52 usec command pulse below spec, and it would then depend on the ‘extra’ room a particular manufacturer provided in their decoder.

There’s some, very little, room to work with in there, though. They allow that there can be a 3 usec difference between the + pulse width of a 1, and the negative pulse width. It may be possible to expand on the circuit you propose to elongate the positive pulse swing, stealing a little from the negative side, but even with that I’d have to experiment to see if the decoders I get can understand. It’s quite tight. The total duration of the 1 is supposed to be a nominal 116 usec, and at 38400 it would be about 104 usec. On the other hand, 115200 baud * 7 samples works out to not quite 61 usec, and that seems a little more comfortable. If I had a 16C650 and could run at 230,400, the timing could be made to match 56 usec with 13 samples, right near the center of nominal.

GremlinSA
July 17th, 2007, 05:42 PM
Looking at the Spec's of Thomas.. I think your right.... Track reversal circuity may just be the beter method.. With some carefull layout and a good design you can get away from the need to signal Thomas to switch direction.. (this will involve adding only a bridge rec to the decoder circuit).

What we'll look at is using a track length about 2 inches longer than the longest engine that will run on the track (Ie. Engine length = 7" then track = 9"). We then glue a small magnet to the center of the bottom of each engine. (we want these as close to center as posible on the longer engines ~ 3.5"). and on the tracks we place the Cassette head sensors at 4.5". something like this..
http://i141.photobucket.com/albums/r78/Gremlinsa/other/Track-layout.jpg
Or we could go with two magnets on each train, on the outer edges, outside the wheel edge. and use only two sensors.. Like this..
http://i141.photobucket.com/albums/r78/Gremlinsa/other/Track-layout2.jpg
This will be the easier circuit to build (and somewhat cheeper - reduced parts list..)

As the magnet passes over any sensor the mid tracks switch to the same polarity, the Engine will ride over the break without problem, as the lead magnet passes over the next sensor the circuit will switch the isolated sections tracks over, the Engine might stutter for a moment, but should continue fowards.. This is also a smart system as stopping and revercing the engine at any point wil not confuse the switching..

The three sensor system has a problem that if the engine reverses while directly over the center sensor it will backup over out of phase tracks.

Also the two sensor system will not be adversly affected by stray signals triggered from any metal on the engine..

Off the top of my head parts required.. Two Op Amps (CA3140), flip flop (Nand Gates, 74LS00), two tansistors and four fets (or even 1 tansistor and a 2 pole Nc/No relay) - The relay option, although cheeper, may leave a bit of noise on the line due to contact bounce and not a good idea with digital data..

With the timing conserns of the Serial port, i'm sure we can find happy line where the signals will match.. I'll look into different methods for adjusting the timing, but for now i can think of using two 8 bit shift registers ( serial to parallel at 19200 baud, and then parallel to serial at 18200 baud) but this involves two clocking circuits, and a little bit of RTS CTS latching...

And my software only shows 16 bit shift registers (74LS673 & 74LS674) .. ahh Yes the software, I'm running Eagle Layout Editor 4 light...

Hmmm , Just thinking now, what about the parallel port, Putting the Bytes onto the parallel port, we could use some clever signaling to pace the bits at the right timing..

When the byte is placed on Data 0-7, nStrobe goes low , We pulse nAck high and hold Busy High, Shift the bits, release Busy, and get our next byte..

We might have to use a 8bit buffer here as well (74LS240) and work out some clever logic for the Busy signal. so that there is no latency between bytes on the bit shifting..

This circuit will be much bigger and may cost much more than just double the serial circuit, Although there are higher benifits in it...

K enough from Me....

Gremmy.....

GremlinSA
July 17th, 2007, 07:09 PM
The total duration of the 1 is supposed to be a nominal 116 usec, and at 38400 it would be about 104 usec. On the other hand, 115200 baud * 7 samples works out to not quite 61 usec, and that seems a little more comfortable. If I had a 16C650 and could run at 230,400, the timing could be made to match 56 usec with 13 samples, right near the center of nominal.Firstly let me say i got the coding the wrong way round earlier... I swapped the '0' and '1' data bit codings around :sick: ... only twigged when i re-read the thread now.. Now with the correct info i'll be better able to assist ;)

BUT You know, you've got the answer here... only after sitting doing a few calculations and checking back on your needed numbers did i work it out ...

you need the High time per wave to be between 55 - 61 usec, the total length then has limits of ~110 - 122 usec... using the 115200 baud our first '1' is sent with 7 bits high and 6 bits low (13 total @ 112.8 usec) and our next '1' is sent with 7 / 7 (14 total @ 121.5 usec) giving us a nominal time of 117.2 .. Very close to the given 116, and both are within our given limits... Only our initial Low is at 52 usec, But i'm sure that the DCC has forgiveness due to switching latency, Inherent capasitance of LONG parallel Lines, etc... so a slightly short low should pass no problem...

Parallel circuit is going to work out way too much (mostly because of the timing needs) so working with Serial is better, as we have a Accurate clock tick (Better than any circuit i could design) and no bit shifting (done on the UART in the PC for us)...

Gremmy...

GremlinSA
July 17th, 2007, 08:02 PM
Hmm... I eventually got to read the DCC document...

DCC Transmiters are required to use 55 - 61 usec per bit part, But DCC recievers are allowed a broader spec of 52 - 64 usec per bit part.. and a crucial part is that the High and Low bit part are not to differ by more than 6 usecs.. So using 115200 Baud with 7 bits per part will be very nicly within spec.

Gremmy...

JVene
July 17th, 2007, 10:29 PM
You have a strong point about the engine reversing in the middle of a reverse loop isolation section - I think I'd give the software smarts to make sure the command for that should be withheld until the engine leaves, once it has entered - not even allowing it to stop or slow beyond some pre-tested speed.

I'm beginning to prefer the serial port over my previous notion of using the audio output if I can get a solution to a track reversal section in mind.

The serial port at 115,200 fits quite nicely into the timing allowances of the specification, and I see my own serial ports won't support 230,400 for an even closer fit, but 115,200 is quite good.

When I was more focused on audio, I intended to rely on the closely synchronized relationship between two audio channels to give me control over the phase relationship of an isolated track section in a reversal loop, making everything an audio/programming solution.

With a serial port solution I think I'd be better off switching the track with a command to a stationary decoder, probably on a simple DPDT relay switch powering that section of the track. The noise going to the DCC would be ignored by the engine's decoder, power interruption would be milliseconds, so probably unrecognizable, and ultimately no more expensive or complex than a second channel of power.

There's one more twist. :)

I'm ignoring any communication from decoders back to the computer. Any feedback from sensors is outside the DCC standard, and I'm fine with that for this project.

If this moved from one project to another, larger layout, I may have to consider that portion of the DCC standard that accepts short bursts of data transmitted back to the computer, which I've not thoroughly researched. They do state that the power device must cut out if it senses a return data pulse, but I see nothing in the standard (in my short read of that part) that discusses how multiple decoders avoid collision - it sounds like coaxial ethernet in slow speed. I'm not even certain how much that feature is used, or how well it's known to work.

I wonder if anyone has ever thought of bluetooth for trains.

dglienna
July 17th, 2007, 10:41 PM
The parallel port would cost more than the board!

USB would be best.

GremlinSA
July 18th, 2007, 11:19 AM
The parallel port would cost more than the board!

USB would be best.
http://i141.photobucket.com/albums/r78/Gremlinsa/icon_yelrotflmao.gifhttp://i141.photobucket.com/albums/r78/Gremlinsa/icon_yelrotflmao.gifhttp://i141.photobucket.com/albums/r78/Gremlinsa/icon_yelrotflmao.gifhttp://i141.photobucket.com/albums/r78/Gremlinsa/icon_yelrotflmao.gif

Nice one...

GremlinSA
July 18th, 2007, 12:12 PM
You have a strong point about the engine reversing in the middle of a reverse loop isolation section - I think I'd give the software smarts to make sure the command for that should be withheld until the engine leaves, once it has entered - not even allowing it to stop or slow beyond some pre-tested speed. You could make it a compleately stand alone unit. Let it draw power from the tracks. The two Magnet - Two Sensor option allows the unit to be completely self reliant.. (Of course ensuring that the circuit switches the correct way...)

A simple Schematic for you to look over...
http://i141.photobucket.com/albums/r78/Gremlinsa/other/TrackSwitch.jpg

I've seen many projects with this simple design (Have not built one myself yet). The magnet passing over the Inductor Causes a flux change (Like a transformer). Op amp picks up this flux change and pass it over to the Nand Gate Flip Flop. The Flip Flop, drives the relay. Simple and very effective..

The circuit will need some testing to get them right but that should not be too difficult..

Gremmy

dglienna
July 18th, 2007, 02:03 PM
Cool USB Section

http://www.beyondlogic.org/