Speed Matching Re-Invented (Video#90)

[@pierrelambert446]

I love this innovative approach. I can’t wait to try it out. As I was looking at your purples hat measuring car trailing the engine. If we don’t care about a prototype look. I guess we can make the floor of the car the actual pcb board and screw the truck directly on the pcb. For this I guess a washer will be needed so the spacing between the wheel and the pcb is right. At lease for n scale it can make sense as it will be hard to hide in a box car anyway.

[@IoTT]

A track measuring car is always not exactly prototype like, I guess. In N scale, the difficulty is not to exceed the allowable profile of cars. On a test track like in the video it is less critical, even though I also had some problems with the Stick touching the signals. Therefore I think for N scale the Stick definitively needs to be in upright position, but I am using still the old prototype board, so I had to lay it flat. The distance between axle and sensor chip of course should be as small as possible, especially when using only 2mm magnets as I do here.

[@johnzubrickas5235]

Pure genius Hans!

[@IoTT]

Thank you, but in fact, as I learned today, somebody else has done automated speed matching before. Maybe with more limited hardware, but the idea is not really new ;-)

[@DaveSmith-Robspalu]

Great idea Hans, look forward to giving this a try when the hat becomes available.

[@IoTT]

Thank you. I still need to finalize the board, but it is coming.

[@Hal-Zuzzu_Model_Railway]

Very informative and educational. I enjoyed that. Good to see someone going deep into the details of what makes these locomotives work at a realistic scale speed. Thank you :)

[@IoTT]

Glad you enjoyed it!

[@IMRROcom]

I have place a boulder creek engineering speed step sensor into a MTL 6 axle drop bottom flat car with the inner wheel set running the magnet.

[@IMRROcom]

This is something I looked at years ago, some sort of PLL or feed back loop but at the time the consumer chips that we had like the Basic Stamp were not up to par with what I wanted them to do. Will be following this, This is something I wanted to do in 2000, just took someone 22 years to get to this point. As a follow up, Running NCE. But if this works with a cheep Digitrax system, that would be great.

[@IoTT]

Yeah, that was the time of the PIC controllers ;-) Luckily, today's controllers have a little more computing power.

[@IMRROcom]

@@IoTT True, I worked at intel for 21 years as Sr. FAB Tech. I have seen the change from the wafer level.

[@mortenhalberg2941]

Playing with speed curves for a while, i'm left with the same conclusion, that the motors is in pure shape. Using the 28 speed curve, putting all at same number/speed/volume (150), and messuring with speedtrack, I have 3 drops in motor performance. Speedstep 7,8 and 23, levers a 20-30 km/t less than alle the other. I think this make it very hard to speedmatch trains, as speedstep that follows the drops, has to be much lower.

[@IoTT]

This is super interesting. Now, if you put all speed steps to the same output and you get speed differences, that would indicate a change in the decoder output, I think. What decoder brand/model did you use for this test? Did you try with other brands? I guess I have to do some more research on the topic of decoder and motor quality ;-)

[@chrisschilb7415]

Great demo. I’m interested interested in this when it’s available. I presume this will work with NCE’s PowerCab.

[@IoTT]

At this time, unfortunately, it is for LocoNet only, but NCE support might be a possibility. Stay tuned for more information.

[@jurigelato4366]

I did some experiments with some N-scale locos. My test track has a length of around 18m. I placed 2 locomotives on the opposite side and let them run the same speed and see which one runs faster. This test showed that even with the same model and decoder they run diffeerently. It can be that loco 1 runs faster than loco 2 (as you would say the speed difference is well acceptable) and after a few minutes this changes without any throttle changes. Also it can be different for slower and higher speeds. There are differences I did not mention yet. The P I D settings of the motor driver set in my ESU decoders with the auto setup of cv54=0 function imo influences the speed curve as well. Did you measure the curve with acceleration in both directions only or also deceleration as well? For me it would be helpful to know some grassroot rules for which criteria that must be considered. I struggle to consist different brands in general even if they are controlled by ESU decoders of the same generation. What do I need to do when I want to consist 2 (or more) locomotives where vmax is 70Mph and 100Mph respectively? My roster is 3 point linear programed with CV6=(CV5-CV2)/2+CV2 Also CV3 and 4 influence consists. Then I think traction tires require more accuracy in consist setups unless you don't mind excessive wear of the locomotives and debris on track or even traction tires falling off wheels (happened on.my FEF UP 844).

[@IoTT]

I agree, the quality of the can motors of N scale locomotives is relatively disappointing and their behavior depends on many variables. I measured the speed of each step in both, acceleration and deceleration mode. The results are different, but mainly a linear shift of the curve, so to analyze it, it is sufficient to measure either or, I am doing it while accelerating. I also found that it is better to have the load compensation on. Without, the speed of the unloaded locomotive tends to be ways too high so that it could slow down if cars are added. Load compensation makes it much more stable and predictable. Running consists of course is a different story. In general, load compensation should be activated in just one locomotive, while the others adjust to the resulting speed by adjusting the pulling force. DC motors react rather significantly to load, so they can adjust a rather large amount without wheels spinning. If you run two locomotives with different prototype max speed in the same consist, you want to make sure that they run the same speed at the same throttle position. And ideally, the maximum speed of the slower locomotive is achieved when the throttle is at 100% or you have an operator rule not to exceed a certain percentage. That can easily be achieved by calibrating the scale speed to a throttle position like I do in this video.

[@knutschwichtenberg7871]

@Hans: Great idea. Which components of your universe are required to use this function? Do you have an idea when the measuring device is ready and available?

[@IoTT]

Thanks. If you have a LocoNet system with connection to JMRI (e.g. LocoBuffer), all you need is the IoTT Stick and the PurpleHat sensor PCB, which will be available in the Tindie store in a few weeks. The IoTT Stick can then connect via Wifi to JMRI using the LocoNet over TCP server.

[@paulantoine1696]

Do you imagine the difference in speed/step forwards vs reverse might reveal a mechanical issue in the loco?

[@IoTT]

Most likely it is a systematic problem with this particular locomotive and I guess a few drops of lubricant would help, as it is normally the case. But then, after doing a lot of measurements, I am fairly disappointed with the performance of the motors and gears in these Atlas locomotives. Getting a half way decent speed curve is somewhat challenging, and I am sure at this point, it is the locomotive, not the sensor. If you watch closely, you can even see in the video that the speed is not even nearly constant. The slightest grade even when it goes over a straight section of a turnout makes a difference I can see in the sensor. Also, speed for step x is not the same if reached from a slower speed compared to when the locomotive is coming from a higher speed. So, some low pass filtering of the speed curve is definitively needed. Another way to get remarkably better results is activating Back-EMF for speed measuring. That takes care of changes in the rolling resistance.

[@IMRROcom]

It is the rotation of the magnet and the motor, the little DC motors are not perfectly symmetrical in both directions, This pick ups can be off just a little bit in on direction vs the other providing more torq one way but more speed in the reverse rotation.

[@geoffreymcdermott65]

Since the IOTT stick configuration can bridge Loconet to DCC at least at the command level, it should be able to issue Loconet speed messages that JMRI could sned tyhe appropriate commands to whatever command station is in use. Am I missing something?

[@IoTT]

No, the IoTT Stick can't bridge between DCC and Loconet. It only can forward either DCC or LocoNet to e.g. an MQTT broker, or receive them from a broker. But it can't convert a LocoNet message to DCC (which is command station functionality) or convert a DCC message to LocoNet (which would be really tricky to do as DCC does not contain e.g. slot management related information). For the time being, I therefore added a WiThrottle client to the IoTT Stick, which allows PurpleHat to run speed commands via JMRi to most command control systems. Unfortunately, WiThrottle does not support programming commands, so that part has to be done using DecoderPro. But at least, PurpleHat can send back roster files with updated speed table information, so the extra effort is limited.

[@geoffreymcdermott65]

@@IoTT That should be adequate.....I didn't expect the stick to actually program the decoder(s), so just having to data to write to the decoder will be more than adequate to make the results practical.

[@HumancityJunction]

Is the Purple Head car something tht is purchased or made?

[@scottericcatalano596]

It's something that Hans will offer in his tinde store

[@IoTT]

The PurpleHat sensor board will be available in a few weeks in my Tindie store. I will also publish the board design on Github, as usual. So you can build it for your self.

[@HumancityJunction]

@@IoTT I just bought the purple hat sensor board and the IOTT stick. Is that everything I need to do this speed matching.

[@IoTT]

@@HumancityJunction Yes, you are good as long as you have JMRI or another software the Stick can talk to to make the locomotive move., The Stick can communicate via WiThrottle or Loconet over TCP protocol. JMRI supports both, but Loconet over TCP I believe is only available if you have a Loconet system.

[@HumancityJunction]

@@IoTT I have a WiThrottle server setup, so that is likely the easiest. I am running a LocoNet system as well, but have not used LocoNet over TCP yet.