Dedicated Test Track

  After working on the speedometer inner workings for the end of 2017 and spring of 2018, it become evident that once the readings of the speedometer were post-processed, any formulas found for the distance would have to be tested on real track. There are a number of reasons this is so:

• Difference between rolling stands and real track - running on real track could provide slightly different results than the ones obtained from a roller stand
• Effect on load - on a rolling stand the effect of pulling a load (eg multiple cars) cannot be studied. But on real track this can be easily seen
• Value-collection differences for speedometer - the process of obtaining the data from the speedometers might be affected by several factors (eg wheel slippage against the speedometer) that could affect the outcome itself - the formulas. The real track would have to validate the formulas obtained as such

Using a section of the model layout, as done previously, is not the best way of moving forward. Repeatability of tests is not easily achievable on a section of the layout itself, nor can specific detectors be mounted at particular intervals. A dedicated test track becomes mandatory. Which entails building a series of boards in order to support that length of track.

  Initial thought went into how this test layout should look like, in order to support measuring the stopping distance automatically between runs. The end result involved a length of about 3m, and a width of a bit over 1m. Since this length cannot be accommodated by a single board - since it will become impossible to move this ever, nor would the current space permit it - the whole structure would have to be built in sections, that can be assembled together and disassembled for storing.

  Realizing I had practically no tools for doing any precision woodworking in the current place I live in, in the beginning of June this year I went ahead and purchased a column drill press - the Bosch PBD 40. This was followed at the end of the month by a table saw - Bosch PTS 10 (the link is in German, couldn't find one in English). I quickly discovered that the PBD 40 - although can be rotated so that it drills into longer pieces of wood - needs a sturdy base. What was purchased next ? The next post will detail it.

Speedometers

Since initial attempts at getting the real-time speed for a locomotive as this decelerates and comes to a stop proved cumbersome (to say at least), I've looked around to see if anyone manufactures devices for reading the instant speed of a locomotive - and more importantly - sends this info to the PC. Sure enough, I found Bachrus, which were doing this for quite a while.

I've went ahead and ordered 2 such speedometers - which are really just regular elements of a classic roller stand with a mechanism to relay the wheel speed to a PC, along with some other "saddles" for placing the rest of the wheels. The first photo shows 2 regular saddles under the left bogie of the Brawa V100 and 2 speedometers on the right bogie - easily identified by a red wheel each - positioned in opposite directions so they can successfully fit on the same bogie. The purchase of all the kits was done in August 2017. 

   Unfortunately, while writing this post, and not understanding why their website isn't reachable any longer, it appears that the company owner - which was kind enough to provide technical details over email at the time - has since retired, and as such the website and Youtube channel no longer work as of today (Nov 2018). Nonetheless, the link above contains a pointer to an archive of the website as it was back when it was up.

  Back to the speedometer itself - the way it works is similar to the old ball mouse. The red wheel of the speedometer is connected by a shaft to the black wheel with "slits" - as seen in the 2nd photo. These "slits"either let - or prevent - light from a LED hit an optical detector located across. This can be seen very well in the 3rd photo, showing the same black wheel as before mounted in its place, where the enclosing "chair" - soldered to the green PCB - has a pair of LED emitter and detector that end up resting on each side of the wheel. The wire seen leading from the edge of the enclosing is connected to an interface (photo 4) by means of an audio jack. The other end of the interface is connected to a standard USB cable, which is then hooked to a computer.

  I've spent quite some time understanding how the device works internally. The technical data received from Bachrus - as mentioned above - pointed me in the right direction. I needed this in order to understand when are the speed values sent across the wire, and also to know the expected accuracy of the device. Keeping the nitty gritty details out for now, the speedometer counts the time it takes for a "slit" to pass in front of the optical detector. The "counting" is done using a timer clocked at 1.5 MHz, powered by a PIC18F13K50 microcontroller inside the interface (the black box saying "MTS-DCC"). Once the "slit" has passed, the timer is stopped and the value noted. The interface averages 4 such consecutive counter values, and sends the value across the USB cable to the PC.

  As for the accuracy of the device - there's nothing mechanical I had at hand that would come close to rotating with a constant speed. A locomotive - although on track seems to be cruising at the same exact speed - is shown by the speedometer to vary its instantaneous speed quite significantly. The next best thing was "simulating" a perfectly constant rotating black "slit" wheel. How ? By tricking the interface into believing it's receiving signals from the speedometer, when in fact an emulator circuit is generating specifically crafted electrical signals, timed very accurately. This was done using the AWG (Arbitrary Waveform Generator) module of a PC-based oscilloscope (Picoscope 2206B) - purchased specifically for this - and a couple of electronic components on a breadboard. The results were quite impressive - just take a look at the chart below. In this particular instance the hardware setup was configured to simulate a constant speed by generating pulses every 0.5 milliseconds. The horizontal axis shows the actual time values measured, while the vertical axis shows the number of instances encountered for each time value. Summing the number of values within +/-1 microsecond of the target 0.5 milliseconds, this represents 99.947% of all the values. Therefore at least the electrical part of the speedometer is pretty exact. Provided there's no wheel slippage from the locomotive while running across the red wheel of the speedometer, the values measured should be pretty exact.

  As for the formula for the instant speed, and the speed variance measured for the locomotives tested, this will be treated in a future post. Otherwise this introductory post would become quite extensive.

Update 1/5/2020: Bachrus has since closed down. The specification that was provided to me back when I wrote this post is here.

It's (not) About Time !

It's been quite a while since the last post. Quite a few things happened - despite no activity here - including moving to a new place 2 years ago, purchasing various wood-working equipment, buying a PC oscilloscope and attending my first Nuremberg toy fair, just to mention a few.

The layout I was working on is still accessible, and the plan is to eventually finish it, however for now the focus is continuing the work concerning deceleration. Continuing where I left off the last time, right after obtaining a formula for the approximate deceleration time for the ESU v3.5 decoder, used in their Brawa V100 locomotive, the problem is that just knowing this piece of information isn't enough to determine the length of track the locomotive will travel while decelerating until standstill.

This can be easily seen through a quick example. Click on the picture to enlarge the sample. There are 2 charts representing instant speed (s) versus time (t), taken for 2 different decelerating objects. Both objects are travelling at a constant speed 3 for the first 3 time units, before starting deceleration at t=3. They all reach standstill at t=7. The first one has a more "smooth" speed curve, going through intermediate steps before hitting 0, while the second one cycles abruptly from speed 3 to 1 at t=4. Computing the distance travelled yields 17 (3x3 + 3x1 + 2x2 +1) for the first object, and 15 (3x3 + 3x1 + 3x1) for the second one. Therefore despite taking the same time to decelerate (4 time units), the distance travelled is not the same.

Knowing that obtaining the distance travelled will be needed as well, I got to work in September 2016 trying to get the required data. A tripod (Manfrotto MK055XPRO3-BHQ2) was bought along with a slider (Dynaphos GT-M80) for taking overhead shots of the V100 and the exact position where it would stop following a deceleration. Since the instant speed is needed as well, the DSLR camera was turned to video mode - and a tradeoff between frame rate (the higher the better) and resolution (if too low, the precise position of the locomotive can't be determined; if too high, the frame rate drops). Since the camera couldn't physically "track" the locomotive in real-time, optical corrections had to be computed and the results adjusted. Why ? Looking from right above the locomotive's end and measuring its position on a track-side ruler - just as seen in the photo nearby - will result in a very different reading than if the camera moves 5 cm to the side (go on, give it a try). Next, the captured videos had to be analyzed - frame by frame - to get the position of the locomotive at each step, apply the corresponding optical correction, and compute an approximation of the instant speed. Not a lot of fun, considering that processing a movie would take about 2h.

How to get the instant speed in a more human way ? The next post will show the way.

Deceleration Formula For ESU v3.5

Ever since work started on this layout, it became evident that stopping trains in front of signals in a realistic manner is a must. In the early days an oval track loop was used with detectors mounted at various points to perform some measurements. I would say copious amounts of time have been spent over this operation during the years, with scores of written pages.

The first thing was getting a consistent terminology. It was during my discussions with Lenz in the beginning of 2010 - when I couldn't figure out how the decoder in the their BR66 was working - when this was established. The value displayed on the DCC handheld controller is the external speed step. As a side node, I've never had a need to switch to anything else than the default 28-step mode. Internally, the DCC decoders use the internal speed step, which translated into the voltage applied to the motor. Separating between the 2 allows creation of custom speed curves, allowing for example accelerating in small increments at lower speeds. The decoders themselves can use 2 modes of operations: 1. CV2, CV5 and CV6 are used to specify relative values for the start, max and medium speed respectively. 2 a user defined speed table is programmed in a specific set of CVs (for ESU LokSound v3.5, this is the range CV67-96).

However trains also have acceleration and deceleration, which DCC models by using correspondent registers for each: CV3 and CV4. The NMRA standard makes things very simple, by saying that the time taken to cycle between 2 subsequent external speed steps is equal to CV3 * 0.869 / .  Unfortunately in practice things aren't that simple. Lenz uses a different formula, based on internal speed steps, and ESU doesn't seem to implement it also.

In august last year I spent almost one day in getting measurements for the Brawa V100, equipped with an ESU LokSound v3.5. To be more exact, the goal was to answer the question "what is the formula for the time taken to bring the locomotive to a stop ?". A section on the layout itself was used for measuring, with several lines of C# code written to send instructions to the Lenz LZV100 via the Lenz LI-USB-Ethernet interface. However since I had no way at the time to detect when a locomotive came to a stop, I had to sit next to the track and press a key when the locomotive would stop - *every* time. There wasn't enough data to see a pattern, so solving this problem was postponed.

Original sheet containing measurements
results for the Brawa V100 tests
done in August 2015

The issue to be solved was detecting when the locomotive was actually stopped. With this out of the way, measuring tests could be fully automated. Since there are already quite a few Phidgets boards I've bought during the time, a current sensor sensitive enough would do. From past observations I figured their most sensitive one would do the job, so I went ahead and purchased 2 of them (an additional one for 1. backup in case the first one fails and 2. error reduction in measurements by averaging, would this were to become an issue). Hooking one of them to the old Phidgets 1018 board that was no longer used revealed it did the job, the only glitch being measuring rapidly dropping currents (eg suddenly breaking the circuit) wouldn't result in a 0 value being read out, however for locomotive under normal deceleration rates this was no issue.

The Hardware setup

Completing the hardware setup involved getting the right number of coils around the current detector. Being an AC current detector, only one of the wires needs to be inserted through its area. Its possible to reinsert the same wire multiple times through this area, thus resulting in increased sensitivity (albeit increasing error). 2 passings of the wire proved low enough to provide enough sensitivity for when the locomotive becomes stopped versus moving with the minimum possible speed step.

Speed measurement for CV2/5/6 set. Note that
the top 2 straight lines are actually artifacts due
to automatic connection of points in the series

First thing to check was that real speed versus internal speed was linear for the ESU v3.5, or in other words measure the real speed (cm/s) for each external speed step. The default decoder user speed curve - which is linear - was activated using bit 4 in CV29. The code for speed profiling was actually implementing a state machine, along the following path: locomotive gets configured with CV3=1 and CV4=3, in order to allow quick acceleration but a slower stop; it gets sent on its way using the maximum external speed step; when hitting the 1st detector the time is marked; when hitting the 2nd one the speed can be computed, given each distance between the detectors is known in each direction (this IS important, since the distance between detectors can differ depending on the way and based on the detector orientation) - also a stop command is sent; once the idle current level is detected, the external speed step is decreased by 1 and the locomotive sent the other way and the process continues. The data was automatically saved in a .csv for post-analysis. 160 runs were captured. The first thing to notice was that indeed the real speed is indeed linear with the internal speed step, so no surprise here (the correlation coefficient was averaged to 0.26 (real speed / internal speed step). Secondly, when switching to the CV2/5/6 mode for the speed curve, the profile was indeed verified to be as in the ESU v3.5 LokSound manual (pg 19, an online copy here) - namely the speed curve didn't end up as an exponential function (hint: Lenz does this), but as 2 simple lines "broken" at the middle point. Thirdly, if the CV6 value (mid) is greater than CV5, then the detector will simply consider a straight line for the speed curve, based on CV2 and CV5 only.

Brawa V100 after the runs were done

Next, deceleration was considered. The state machine was slightly altered, to consider 4 detectors and operated as follows: CV3 is always set to 1, while CV4 is chosen each time; locomotive gets send with the maximum speed; once the first detector gets triggered, a stop command is sent; once the threshold value for current is hit (signalling the locomotive just stopped), the time it took to stop is marked. Then, depending if the detector behind the 2nd one on the direction of the run (called the fallback detector) is triggered, the locomotive is moved safely until this fallback one is hit. Then the locomotive is again issued a stop command, the idle current value is waited for, after which the speed gets decreased by one and the locomotive sent the other way. This slightly complicated way was chosen in order to leverage a flat section of track between the 2 "principal" detectors, however at this point I think it was just overkill. 252 runs were done. Running in both the user defined speed curve, as well as the CV2/5/6 one, confirmed that the ESU LokSound v3.5 doesn't take into account the internal speed steps, but only the external ones (Lenz does the opposite).

Time to stop versus external speed step, for 4 different
CV4 values, given CV2=3,CV5=35, CV6=13. Note the
linear aspect, suggesting dependency on external
speed step only

The graphs indicated that a linear function could be used to generalize for any CV4 value, provided the reference of this one was slightly moved "up" - to give a few more details, on the graph to the right, the place where all the lines meet is at 1.13 on the vertical axis; the fraction of the differences between the time value for 2 curves corresponding to the same external speed step  minus the "base" point (1.13) will roughly be the same and equal to the fraction of CV4s involved (eg time value for external step 20 on the top line, corresponding to CV4=20, minus 1.13, all divided by the time value for external speed step 20 on the 2nd line from the bottom, corresponding to CV4=10, minus 1.13, will equal approximately 2, the same ratio of 20:10).

A final formula based on the linear functions for 2 sets of results belonging to CV4=5 and CV4=10 was deducted:

t(E, CV4) = (a*E + b - B) * CV4 / 10 + B

where a=0,337; b=0,479; B=1,13.

The difference between the real measured value and the one computed based on the formula usually stays inside 0.2 seconds, but there are exceptions.

Corrections On Wiring the Viessmann 4016

Soldering the wires for Viessmann 4016

Since these days I've been starting to prepare the landscape for the retaining walls that will sit behind the Faller station, supporting the track going up, things have to be in order. A bunch of wires however sat in the way - the connections for the only Viessmann 4016 signal on the layout, not yet installed. After testing each LED of the signal using the transformer, the signal's own wires were soldered to the feeders already on the layout. However when powering up, with power from the panel board and hooking up the laptop to the USB interface controlling the aspects for this signal - something odd: the main signal would not show Hp2, but only Hp1 (a list of signal aspects can be found in the Viessmann 401x manual, there's one online here). Also the Hp0+Sh1 wouldn't turn on the shunting lights. On the distant signal part, it was even stranger - only the ge2 LED will be on, and cyclic through the aspects wouldn't trigger any change.

  Turns out there were 2 factors causing it:

  1. The plugs at the end of the wires coming out of the Viessmann modules and leading to the connectors on the panel board had poor contact. The fact the the tiny metal tubes - where the plugs fit - are actually made out of two halves doesn't help, since if the bent wire happens to slide between, there will be no contact. Fiddling with the plugs made the dark LEDs issue go away

   2. I wrongly *assumed* that it's the brown output of the Viessmann transformer that's supposed to to be used as input to the desired states on the 5220 module, but it turns out this isn't so. After quickly reading through the manual and running across a diagram for a normal + distant signal on the same mast, showing the wire leading to the rt1 LED being used as input for the "dark aspect" of the distant signal, it become obvious it's the yellow that's needed. Also, I only accounted for 3 aspects of the distant signal in my original plan, when in fact there's an additional one - Vr0 - displayed when neither of the inputs are ON. Looking back I didn't knew what the aspects were supposed to be in the first place, nor what the correct wiring was. Reading the manual thoroughly made things clearer.

As for the wiring of the distant signal, in order not to use an additional relay of a Phidget 1017 (there's still 1 left on one board and 5 on another), I've took advantage that the "dark aspect" of the distant signal is only "showed" when the main signal on the same mast is in a Hp0 state (or Hp0+Sh1). By also using the fact that all the relays on the 1017 are DPDT (double pole double throw), the output selecting between the groups Hp0/Hp+Sh1 and Hp1/Hp2 was used to toggle between feeding the "dark aspect" input, or serving as input itself to yet another relay switching between Vr0 (essentially no wire connected) and (yet !) another relay switching between Vr1 and Vr2. The photo below shows the yellow wire, which is connected to the yellow Viessmann transformer output, used as input. There are 2 green wires used as outputs - the one labelled "OFF 5220" is actually the one controlling the "dark aspect"; the red electrical tape further up was used to cover the soldering needed to extend this wire, originally connected to a different relay. The other green wire is the one leading to the stairway mechanism mentioned above - the empty output on the next relay can be clearly seen.

Painting the Roof and Auxiliary Elements of the Faller Station

Although the roof of the Faller station came out of the box sporting some nice burnt out marks, given the technology used to produce it, it still didn't look quite all right and proper painting had to be done. Along with the roof, 4 other element types had to be painted as well: the rain pipes, benches, trash bins and the window sills being mounted on the roof itself.

For the roof itself, the following formula was used: 

- 0.6 Tamiya Yellow (XF-3)

- 0.4 Tamiya Flat Red (XF-7)

- 1.0 Thinner (acrylic)

3 coats were applied, out of which the first was a light one.
For the rain pipes, benches, trash bins and window sills, it was decided to use gray for all of them - one of the reasons being that the box cover image actually had these gray as well. All were simply placed on a sticky tape side up - fixed itself on 2 perpendicular pieces of sticky tape. The "stickiness" was strong enough to hold the pieces down under the air flow of the airbrush. 3M Vinyl masking tape was used on certain parts of the window sills, since those will be glued on - and paint shouldn't get in the way.
The rain pipes only also had 2 coats of Tamiya Smoke, so they get a touch of metallic look.

Final roof color

Auxiliary elements getting ready
to be airbrushed

Bench before being painted

Bench after 2 coats of Tamiya J.N. Grey

Rain pipe detail after painting
with Tamiya J.N. Grey

Rain pipe detail after painting
with Tamiya J.N. Grey and 1 coat
of Tamiya Smoke

Rain pipe detail after painting
with Tamiya J.N. Grey and 2 coats
of Tamiya Smoke

Glueing the Roof on the Faller Station

  Once the decision to have the roof of the main station detachable was made, the next step was how to actually glue this in place. Additionally, painting will also have to be done, since (1) the bare plastic won't look well under any kind of lighting and (2) there needs to be some tooth for the weathering powders to actually adhere to.

  All needed in order to have one continuous piece ready for painting was to glue the main sides of the roof together, followed by the 2 small panels located on each side and also the ridge caps (a long one for the joint of the 2 main sides + 2 smaller ones for each panel-set on the sides).

  The pieces were first washed (a drop of liquid wash detergent added to a some warm water) and completely dried, while also removing some of the burnt plastic that resulted from the laser cutting process, since in some cases this was found right on the joints where adhesive would have been applied. For the 2 main sides and corresponding ridge cap, Bison 5-min Epoxy was used, while for the rest - Bison Plastic Cement. Reading around the web suggested that the epoxy is superior in strength to the plastic cement - albeit a rather short and subjective process on my part, hence the reason for it being used on the main roof sides. The masking tape was only used to keep the side panels together, given that like this they would rest just fine, unable to fall off until the cement set.

  It was also a good chance to test the Proses Magnetic Clamps that I bought one year ago, and they did a really good job in holding the main roof together until the epoxy became solid; luckily enough, there was just enough space between the paper mask and the roof for the underside of the clamps to fit into.