DIY Track Measuring Car for HO and N Scale (Video#87)

[@geoffreymcdermott65]

I built and designed something functionally similar using an Arduino NANO and an LCD display in a 'dedicated' car. My design goals at the time were that it needed to be powered from the track, and included some super capacitors to keep things going over problem spots. That was needed because the HW I used wasn't exactly low power. The display showed current speed in MPH and KPH, plus an odometer function and average speed (I needed someting to fill up the 4-line display). The car is currently at my club, and I'll be able to get photos in a day or so. My design was 4+ years ago, and used 5 magnets attached to the inner surface of a wheel, and a hall effect sensor on a small PCB mounted on the truck with the magnets. It works well to this day. Your configuration is better and simpler, as it doesn't require anything other than the magnets below the car. Allowing for an external battery supply to extend the time that your system can operate is something you should consider. My experience with the stick modules is such that the battery didn't last very long. Obviously, using the stick will allow remote access to the data, which was in my original design, but never implemented. It used a 433MHZ radio module.

[@IoTT]

Thanks for sharing. I'd love to see pictures. The advantage of the 3d hall sensor is that it also can detect the direction the rotation, which will become important once I start using the IMU to do the Layout GPS. The battery of the Stick is indeed a weak point. Using the Stick plus, which has a larger battery, helps some. I am getting about 20 Mins of run time with full bright display and Wifi connected, sending a data update every 500ms. t snot too bad, but I plan on adding a connector for an additional battery to the final board design. I just tested it using a 750mAH Li-Ion battery and got an autonomous runtime of about 6 hours. That seems like a workable number.

[@robleathley6024]

That N-scale car looks very interesting! I can see that helping out a number of things. One idea would be speed matching DCC locomotives. Look forward to further developments in this idea.

[@IoTT]

Yeah, that crossed my mind as well ;-) We will see what is possible ;-))

[@jurigelato4366]

I am an N-scaler. My idea would be to use this for setting CV5 and CV6. It could be used to log speed variations due to hot/cold motor, dry vs well lubricated, running without cars and many cars, seeing the influence of ascend and descend of track. Another option for N-scale could be to synchronize chuffs of steam engines.

[@IoTT]

Great ideas. I am actually working on supporting setup of speed tables and/or min/mid/max settings so that speed matching becomes much easier. Comparing runtime characeristics or analyzing the impact of train loads, cold vs. hot motor or the impact of radius and slope certainly would be possible as well. Synchronizing the chuffs would probably be difficult. The frequency of the chuffs, yes, that could be done, but syncronizing to the exact position of the pistons is not possible because there will always be some slippage of some wheels here and there, so the wheel position between the measured wheel and the Loco wheel is changing constantly.

[@IMRROcom]

Boulder Creek Engineering has a N scale car that does distance etc. in N scale, I have had it now for several years, but I'm rather interested in what you are doing. Mostly interested in automated speed matching. I have been doing it manual for years, That is why the Boulder Creek Engineering car.

[@IoTT]

Interesting, another one I was not aware of. Same principle with the main advantage that you don't need any wires going below the chassis plate thanks to the wheel magnet. Would be interesting to know what sensor they are using and if they can detect the travel direction.

[@IMRROcom]

@@IoTT As far as I know it does not detect travel direction. It passes the data via Bluetooth to an app on the phone. Not a fan of the app. I would rather have another way to save the data. But it works, It is also not a fan of track nails. The magnetic drum on the axel is very strong and it will pull up nails that are loose or a little snug.

[@donaldkormos5529]

Hans ... this looks very promising!! Only problem I see has to do with magnets already existing underneath track ... permanent magnets such as those used by Kadee couplers and similar. I can't due the experiment, but my guess is that your car might just stall above any such magnet, or at least slow down.

[@IoTT]

Thank you. I never thought about magnets installed underneath the track, thanks for pointing that out. I did some tests this afternoon, and at least in HO scale, it is not a problem. The only thing that happens is a temporary loss of speed data because the sensor is confused by the overlaying field. First I feared it would pull away a magnet from the axle, since they are not glued on, but not even that happened. In N scale there might be a risk that the magnet derails the measuring car if the position of the magnets is such that the car is lifted, but I will have to test that. Another potential problem is that the sensor has an impact on certain activators, e.g. reed switches. But that would not be different from other train-installed magnets, so I don't think it is a real problem.

[@epacm50]

Awesome Presentation!! Do you have plans to develop a circuit that uses "constant actuation/warning time" software for a grade crossing control signal or turning on special effects for a train station? It is very difficult to operate that kind of circuitry on a HO scale layout.

[@IoTT]

Thanks. I am not sure what you mean by "constant actuation/warning time". If you think about a simple thing like crossing gates automatically lower when a train is approaching, along maybe with some blinking lights, you can easily do that using a GreenHat, which provides all you need: servos, inputs for buttons or lock detectors, and LED's. Maybe I should consider making a video that shows how to do that.

[@epacm50]

It pertains to advance actuation on trains traveling in higher speeds. It is smarter than a motion sensor.

[@IoTT]

Ok, thanks. Comes a fast passenger train, we close it early, and in the case of a slow freight train, late. In both cases, the time from when the gate is completely closed until the train is on the crossing, is about the same, right?

[@epacm50]

Correct! That's when additional sensors are added.

[@stefantrachsler2873]

Toll

[@IoTT]

Danke.

[@beyondDCC]

When rounding a sharp model curve, one wheel is gripping the rail and one is slipping. So you have no idea which distance you are measuring on a curve. The inner rail, the outer rail or anything randomly in between.

[@IoTT]

And your point is ... ? Btw, the behavior in curves is not so unpredictable. If the car is pulled, it tends to lock with the inner rail, if pushed, with the outer. The length difference between inner and outer rail for a full circle of track is twice the distance between the rails times Pi. For an HO circle with a nominal radius of 300mm the difference is about 5% (107mm difference, full circle is 1884mm) That's a tolerance I can live with ;-) Of course, if you model maybe tramways and go with tighter curves, the percentage increases.

[@johnkelley9254]

Will you have this for sale

[@IoTT]

It is available in the Tindie story. Check out the link in the description of most videos.