Skip to main content

Reply to "Simulated Brake Spark"

@jockey31 posted:

You guys are awesome! I love the enthusiasm about new ideas. I am a ways off from implementation, clearly, but the ideas are great.

To answer the posed questions;

-Control is DCS

-Soldering Yes

-Arduino (would need help)

Again, since this is not today's project, I think there's value in letting the ideas stew and perhaps others will add to the discussion.

Knowing we're dealing with command-control DCS is important.  Specifically, DCS uses pulse-width modulated voltage to drive a DC-can motor.  The motor pulses are ~20V, thousands of times per second.  If you're not already intimately familiar with the Arduino or a similar microcontroller platform, I don't think that would be the easy path forward. 

Likewise, as GRJ implies, extracting speed by measuring the back-emf motor voltage (NOT the applied motor voltage) is not the easy path forward.  To summarize, measuring the back-emf voltage requires intermittently cutting the path between the motor controller voltage and the motor itself.  When so isolated, the two motor terminals will generate a DC voltage proportional to the motor speed.  This can all be performed in, say, 1/100th of a second for a typical DC-can motor that might be used in O-gauge.  So it could be done but not an easy path forward.

That said, as GRJ suggested early-on, using applied motor voltage is probably the easiest-to-implement proxy for engine speed.  Two end-point examples illustrate why applied voltage is only a proxy for what the engine is actually doing.  1) If the engine is stalled, then applying 20V DC or whatever is clearly a bad proxy for how fast the engine is going.  Conversely, 2) If the engine is cruising along at some healthy clip, then cutting the applied voltage to 0 is also a bad proxy for how fast the engine is going as it coasts down to 0 speed over several seconds.

Detecting drops in applied motor voltage to trigger braking is also problematic especially with command-cruise control.  For example, say the engine is climbing a grade and requires 12V.  Then it reaches the summit and now requires only 10V to maintain the command-control speed.  So the applied motor voltage suddenly drops but clearly this should not trigger the braking effect.  Likewise an command-control engine going around an O-22 curve then reaching a straightaway will see a sudden drop in applied motor voltage.  Again, this event should not trigger the braking effect.

Sidebar.  In re-watching the video of the HO engine sparking, it seems to me that you should not have sparking when the engine decelerates to below, say, 10 sMPH.  That is, do brakes really spark at slow speeds?  Now that I think about it, I believe MTH PS2/3 engines do NOT play the brake squealing sound when the engine is going really slowly and stops.

Back to the matter at hand.  I'm thinking maybe a dozen inexpensive components (less than $5 total) could make a suitable trigger.  A 10-cent bridge rectifier converts the applied motor voltage to DC.  You need this since the train can be going forward or backward so the bridge converts the motor voltage to DC.  The DC motor voltage is pulsing so you need to smooth it out since dealing with PS2/3 20V motor pulses is electrically challenging.  My idea is to smooth out these pulses with a "fast" filter and a "slow" filter.  A filter simply converts the motor pulses to a smooth DC voltage that is easier to process.  A filter can be as simple as a 10-cent resistor and capacitor.  Here's the trick.  And this may mean absolutely nothing to you...but will serve as a reminder to me next year or whenever you re-visit this project.  The idea is to detect when the short-term motor voltage drops by some settable number of volts below the long-term motor voltage.  There are many simple methods to compare two voltage and detect when the difference exceeds some level...maybe 50 cents in parts.  This voltage drop is the trigger to the flickering LED circuit(s).  

flicker led

That you can get a flickering LED on eBay for 30 cents each from a US seller tells me this part of the project should not be a problem! 

Again, a lot of techno-babble above but serves as a thought-diary that I can refer to later...

 

 

Attachments

Images (1)
  • flicker led

OGR Publishing, Inc., 1310 Eastside Centre Ct, Suite 6, Mountain Home, AR 72653
800-980-OGRR (6477)
www.ogaugerr.com

×
×
×
×
×