[pokey_toaster]

I have two locomotives with Kato motors (one Kato the other Athearn) that I use to load coal trains. They have TCS TX4 decoders. I use live loads and only need the BEMF to maintain HO person walking speed while loading the train so the BEMF is set to turn off at speed step 15. I usually load at step 4. I'm using a Digitrax throttle and the locomotives will creep along fine making perfect loads but when I accelerate away from the loadout, first one then the other will appear to drop several speed steps as the BEMF cuts out. Even though both are set to turn BEMF off at speed step 15 they don't slow down at the same speed step on the throttle. I'm using Digitrax consisting and not advanced consisting, basic speed control (not tables) and program with Decoder Pro. Any ideas to eliminate the slow down when the BEMF turns off would be appreciated.

Paul

 

[gregc]

isn't this a momentum issue?

 

[pokey_toaster]

I don't think it's momentum. As I'm accelerating, each locomotive will suddenly decelerate then start to accelerate again. All the time I am advancing the throttle. The deceleration occurs around 12 of 99 on the throttle which is close the 15 of 128 on the decoder where the BEMF is supposed to turn off.

Paul

 

[wvgca]

turn off the bemf entirely, it will show where the problem is ..

 

[pokey_toaster]

The decoders are set up so F6 toggles BEMF on and off. With it off they run fine but are not able to maintain the slow consistent speed needed to load the train.

Paul

 

[gregc]

back EMF momentarily stops providing power to the motor in order to measure the voltage (EMF) generated by the motor. BEMF is a measure of the motor rpm.

in this mode, the decoder drives the motor with whatever voltage is necessary so that the motor speed (rpm) corresponds to the speed setting from the controller.

in a consist, one loco can help the other, the rpm of the motor isn't solely dependent on the voltage the decoder supplies. i'll guess this can be more severe at lower speeds and some decoders BEMF algorithms deal with it better than others

 

[pokey_toaster]

Update. I put them in an advanced consist so I can turn the BEMF on and off as needed. In an advanced consist, I don't need to select each locomotive, it is just one keystroke. It's not ideal but works better. I just turn it on when loading the train or spotting the first couple cars in the dumper.
I'm still interested to hear any suggestions for eliminated the hesitation when the BEMF turns off.
Paul

 

[Severn]

I think "bemf done right" -- the sampling of the voltage which in my mind puts the motors in "coast" or (possibly) "brake" mode to generate a current by which to measure the voltage, which then as folks say relates directly to RPM -- ought to be imperceptible to the user... yes?

 

[gregc]

-- ought to be imperceptible to the user... yes?

i think just a few msec, if that. enough time to disable (set to zero) the PWM output voltage, read an ADC and restore PWM

 

[Severn]

I just want to crow a bit with some background-- somewhat off topic but topical.

I got interested in this BEMF stuff which I'd never heard of before a couple years back with O gauge. I bought some parts, arduino and all that. I read and read online. I understood the concept but not see how to make it work -- not being a hardware person I was a bit lost and didn't understand some of the advanced explanation much at all.

Finally I realized all I needed to do was measure the voltage on the adc pin of the arduino if I divided the voltage appropriately from the can motor (and had an appropriate motor controller) to not blow up the arduino which is 5 volts.

While I not understanding all that -- I did understand the simplicity of reading the rotations off the motor directly with some kind of IR sensor etc... and so implemented that and made a very simple RPM reader with it.

Then having the light bulb moment somewhat later as I just described I managed to get a very simple BEMF working on the same set up -- and can run them parallel.

It works OK -- not so great at the low or high end but matches closely with directly RPM reader "in the middle".

However there's a definite lag that's audible when you coast the motor to get the voltage going. I played around with this but not in a serious way and never got it to go away completely.

That's why I think a better implementation would be more successful and you'd not see any visible lags or jerkiness in the engine. I suspect a full on hardware approach might do the trick and the pauses or coasts can be minimized to the point of not being audible to the human ear with no visible effects on the engine. Perhaps there's some concept of "super sampling" or something that allows lots of micro-pauses to somehow give you the RPM reading etc...

Anyway blah blah blah ... I just wonder about the various decoders out there and how good they do the job. On my one soundtraxx current generation you cannot hear a thing as far as all this goes and performs very good at slow speeds too. I have never seen any jerkiness and so on.

I also wonder at this point why the sound decoder folks don't provide a "1 revolution pin input" for RPM sampling provided by some other device .... seems like that's the way to go in the end and hobbyists might enjoy providing the little bit of hardware to do it.

 

[gregc]

However there's a definite lag that's audible when you coast the motor to get the voltage going.

can you explain this lag?

presumably you know the speed setting commanded over DCC, you have a measure of speed (BEMF) and a motor voltage (PWM) setting. you compare (or subtract) the measured and commanded speed and make a PWM adjustment. No doubt there may be some iterations for the measured speed to stabilize at the target speed, BEMF is not proportional to PWM, but make PWM adjustments proportional to the error (target - measured)

I also wonder at this point why the sound decoder folks don't provide a "1 revolution pin input" for RPM sampling provided by some other device .... seems like that's the way to go in the end and hobbyists might enjoy providing the little bit of hardware to do it.

i believe BEMF is simple and requires no other components except for an connection between the motor armature and ADC input.

i thought some sound decoders require a metal pickup on the back of a driver with a sticky patch exposes metal every half or quarter.

 

[Severn]

I should have been more clear in my long winded explanation of the work. What I did was on the bench. There's no DCC involved. The motor commands are done through the arduino directly to a hardware motor controller. The controller changes its PWM freq depending on various inputs -- and you can set it to coast or even brake. I have not experimented with breaking.

Off the the input leads to the dc motor I've a voltage divide which is just a few resistors to keep the outputs done below 5v -- this does into the arduino's ADC pin. (note this an o gauge motor running on 20v DC... so yes HO motors are just a few volts in comparison)

Then I run the motors, and coast them in a loop every few moments -- which I can change the sampling rate.

And the end result is audible enough but works -- so I am definitely getting voltage read and you can clearly "see it" if you quickly print out a few voltages for a second or so during this loop...

But not doing that and actually calculating the RPM instead using some formulas and various constants measured on the motor -- I at least get a pretty good result in relation to the other method which is using IR to directly sample the turning motor for the RPM -- in other words they are very close (1% perhaps or around it).

It's quite good as I said "in the middle" and drops off noticeably at the ends.

I imagine the DCC decoder folks have spent a lot of money figuring out how to make it better, smoother and so on.

So when I read about one being jerky, I just wonder if they've done a good job. (since my amateur effort is clearly pretty poor although technically functional) I realize these things have been out for some time and so it may be there's been quite a bit of improvement over time.

 

[gregc]

And the end result is audible enough but works

what do you mean audible? why do you think it is audible?

So when I read about one being jerky, I just wonder if they've done a good job.

i believe the jerki-ness is the result of multiple locos coupled together and influencing each other. In this case, the motor speed (BEMF) is not solely dependent on the motor voltage (PWM).

 

[Severn]

audible -- you can hear the engine coast, and come back. I've a very short sample period that I conconcoted by simple hand tuning and even with that you can hear it. i suspect on the track the engine would surge a little, pause/surge ... you'd see it.

i can't see how multiple locos from different manufacturers would work very well at all except perhaps with a lot CV hand tuning -- due to different motors, and dcc bemf implementations. Or suspect it would be terrible.

 

[gregc]

how long did it take to make a measurement and was the motor unpowered (i.e. coasting) during that time.

 

[Severn]

fraction of a second. I don't have the time at my finger tips, I'll try to look at it tomorrow some time. but yes, put it in coast and very shortly you get the build up and can read solid makes sense voltages. I believe I averagd. I experiented with different sample times etc... what I did not do is put it on the scope because I was not getting paid and got lazy.

 

[gregc]

fraction of a second.

1/10, 1/100, 1/1000 ?

 

[Severn]

Looking at the code... Once a second, I coast the motors. After 25 microseconds I start sampling voltage which I do for 3 milliseconds. [note: i played with various values, these are just where i left it which was working] I have no idea how many samples I take or any real details because I didn't actually really inspect it "to the metal".

But i do compare it to the IR sensor results. That works a bit differently. The IR sends a voltage to a pin on arduino. Over some amount its high, and below some amount it's low. I sample the motor 4 times per revolution in the current IR setup. (for bright reflecting patterns on the motor weight symmetrically positioned with black alternating) The pin goes to a interrupt handler in arduino and increments a counter. Once a second I calculate RPM based on the counter and time etc... I take into account (or try) to take into account counter wrap.

The BEMF RPM and IR RPM compare favorably except I said at the "ends" of the power and I don't mean this to be cast in concrete, those were my observations at the time.

On the IR -- one improvement I could make would be to get a solid square wave out the signal -- I didn't bother with this because what I did seemed to work. (I used a hand held RPM reader as a rough sanity check, and looked at the scope and the pin transitions which seemed to compare favorably to my RPM calcs).

Another better improvement there would be a smaller IR package. I looked at some options on digikey but since I actually have no idea what the <blank> I'm really looking for in terms of IR bands and what would be good, etc... I never went further with it.

For HO, I imagine a piece of black/white tape on the HO's motor to wheel connecting rod... and the IR sensor mounted on the chassis in some way to sense the transition in that manner. Many models seem to have this configuration with a motor in the middle and rods to the front/rear wheels -- I guess for diesels at least.


Obviously as you said, BEMF only needs the motor leads.

 

[gregc]

On the IR -- one improvement I could make would be to get a solid square wave out the signal.

you might be interested in encoders attached to the shaft of a motor and used to measure position and speed. They use two optical sensors so direction can be determined as well as increased precision

but as I said, BEMF is well suited for regulating motor speed.

i'm surprised you can hear an audible effect if you simply suspend power for 3 ms while measuring bemf once every second

 

[Severn]

well its "surgey" -- I may now have to dust it off & investigate more deeply. I also did have the idea of moving it to HO and trying again.

as for motors with built in "encoders" -- I have thought of it. My original idea was just use what I had on hand & it was about learning about it not really the end result. I took apart on old williams engine, and scrounged the motors. Then I got a couple of new MTH motors and I have a couple of Lionel motors. They are all very similar models from that chinese dc motor company. cheap cr*p basically.

I did briefly make something for the track that could go back and forth from a wireless connection using a different motor controller and PI set up through wifi -- it was quite a mess, but it did work although it wasn't very responsive. I used a 18v DC battery back from a drill to make that go.