As I talked about in the thread on speed matching, setting up a baseline and matching to it is a pretty good way to start. But now I was thinking that there could be a more efficient way. I am not sure what the level of interest would be, but I thought rather than using the baseline method, that it would be easier and more efficient to let the computer take care of the whole process. My idea is to write a program that would hook into JMRI or other interface to the DCC Command Station, that would just take the locomotive with no programming and auto program on the fly the motor and speed settings. If I were to construct a program that would step through the speed tables and the trim variables to actually calculate the right settings at 5mph increments from 0mph to say 70mph. In this manner, there would be an easy way to make sure all of the locomotives are set for the same speeds. And if all of the locomotives were configured in the same manner, then they would all be speed matched from the start. So if the whole fleet of locomotives was done this way, one could mix and match to their hearts content and not have to look at making the subtle adjustments from locomotive to locomotive. This approach could be further extrapolated for the momentum settings and kick start settings by determining a speed at a fixed distance from the stop position to be the combination kick start and forward momentum. And similarly, from a speed to a fixed distance to full stop for stopping or reverse momentum (not really a valid term in physics, the terms should be positive and negative momentum but I digress). The negative side to this is that the user would need a calibrated test track and the computer interface capability to their DCC Command Station. The test track would further need to have occupancy detection that could be sent from detection sections to calculate the time and derive the speed based on the distance between the detections. For that, access to a real time clock would be needed, ie the motherboard clock of the computer. This would take it out of the native Java environment of JMRI and dictate the use of C/C++ as the programming tool. But that is not here or there because it would be transparent to the user. I am adding it here for open disclosure of the solution. Maybe this was too much information, but I wanted to present the whole picture and see what others think about the idea. Would anyone be interested in something like this?
Dave, This is something that I would love to see, if really possible. I always thought there needs to be an independent way to set a loco, rather than the trial and error approach that is followed today. There would, of course, be locos that still wouldn't be "matched" (i.e., switchers vs main lines), but this would take DCC to the next logical level. The key would be the precision of the calibration and repeatability of the measurements. Accuracy, in and of itself, only becomes an issue if one is planning an consisting with a unit programmed on another calibration track.
Some good points! I will address the accuracy. This can be done in many ways depending on the user situation. Personally, I have a test layout on a 4x8 foam panel that I use. It is broken down into 8 detection sections, but that is just over kill. It can be done with just one section on calibrated track and two occupancy detectors. One as the locomotive enters the "calibrated section" and one as it enters the next section after that. All it really takes is 2 fixed points in space and then the ability to measure the time when the occupancy detector sees the loco in the calibration section and when the next detector sees it enter the next section. From the transit time and distance, the speed can be calculated. If the test section of track is accurately measured. Say 30 inches in length for arguments sake (a single piece of Atlas Flex Track), and I am able to get good transit time information, then this should be the same from layout to layout. Calibration track to calibration track. All that is fundamentally needed is any two points in time and an accurate distance between them. By keeping things simple, it should be as easy as you and I able to consist to as much as we wanted. I see the variance as more of a command station to command station thing though. The more detection sections just add a way for more efficient operation. If you get the right speed from section 1, you now bump up the speed table as the locomotive traverses section 2 and measure again entering section 3 and so fourth. Both have the same accuracy, one is just more efficient. Different locomotives classes like yard switchers and different steam classes would just be done using different top end speeds. I just used 0-70mph as an example. Programatically, it is 0 to whatever in however many steps you want. Thanks for bringing this up so I could clear it up a little.
This is a great concept David!:thumbs_up: The ability to trim the variables at 5mph increments is on target with most speed changes made by the operator. As far as the test track goes any length of track that falls within two occupancy blocks (start / stop occupancy triggers) could be used on any layout with block occupancy detection using a scale distance variable supplied by the user. This scale distance variable could then be used by the software program along with each referenced speed (5mph increments) and a reference standard (say: one scale mile) to extrapolate a time / distance reference point. This technique would use a portion of any existing layout and therefore would require a user input to address each of the two detection blocks. Of course this would be needed if using a test track for the same purpose. An added benefit of this extrapolated time / distance reference point is that it could then be used across the board (no pun intended) to yield a near matching speed layout to layout. Obviously this would imply clean track operating at the same track voltage, block detection, computer with DCC interface and using your software program to mention a few requirements. Jerry
There's got to be some way to access that information since BEMF is used for load compensation . Speed matching would basically be the reverse of load compensation except that it would have to be calculated first, with no train load, then saved as a speed table. Instead of speeding the loco up when drag is introduced (as load compensation does in cases like an up hill climb) Speed Match would slow the loco down, so that it's speed matches the speed of the second unit which is causing drag because it runs at slower pace. Once BEMF is converted to a speed table, thats it. You're two locos would be perfectly speed matched for every speed step. (That's the theory anyways)
There is another simple way of speed matching available. ZIMO decoders have a km/h or mph feature. This converts your typical percentage speed scale on your cab to scale miles per hour? You do a quick and simple one-time calibration run during which the decoder calculates the speed in mph. After calibrating your engines this way, each one is going 30 mph with the speed regulator at 30 for example or 50 mph at throttle setting 50 and so on; so all engines are matched to the same speed. This is in a way similar to the speed matching we already do with the exception that the whole calculation is done automatically by the decoder and you don’t have to do this for each speed step. The procedure is simple: Run your engine through a 1/10th scale mile at medium speed, turn on the headlight when the engine enters that section and turn the headlights off when it leaves the section. That’s it. Regards, Art Luescher ZIMO Agency of North America Home
Well I think that this could also be done on the decoders, but it just isn't there yet. And I am pretty sure Digitrax, NCE and TCS would never think to do something like that This is a pretty cool feature from Zimo, but the cost of Zimo is really too high for the general consumer base. So we need other solutions for systems and decoders affordable to the general population.
BEMF measurement is the method used by decoders to stabilise the speed of a loco over hill and through dale through monitoring the AC voltage generated by the motor as the poles pass the magnets. As it changes with rotational speed of the motor the decoder compensates for this change by inversely increasing or decreasing the DC voltage applied to the motor. Think of it as cruise control. BEMF (EMF = voltage) as a voltage should be measurable with a voltmeter from the motor, or better still an oscilloscope. A rolling bed would be perfect for this. As we already know, speed matching is changing the voltage applied to the motor to maintain the same speed between locos at a given setting, where you take into account the differences of wheel diameter, motor characteristics, gear ratios, etc. between locomotives when matching. I believe it is best done with BEMF off. What I think some are thinking of is dynamic speed matching on the fly. Tricky if not mostly impossible without the use of a programme to monitor all the locos involved, most likely through a transponding arrangement a la F1 racing...
I had heard of this being done before, and after a little searching I found this: Oregon, Washington, Navigation and Railway: Triple Header and Test Track It may not be the only instance. Just in case you don't want to re-invent the wheel... EDIT: Reading down through the comments on that page, it appears that the script and instructions were posted to the JMRI yahoo group at some point.
