Signal Project

[mrp]

Hi kvp,

 

I’m embarassed to admit it now, but I hadn’t even considered PWM synchronizing until after I’d built an initial prototype and watched with disgust as the train motors and lights all went crazy when driving between blocks!

 

And yes - you have immediately spotted the fatal flaw in my design - synching between stations.  I wrote some amazingly complicated code that used a PID controller driven by a short burst of pulses sent once per second over the CAN bus to perfectly synchronize each MiniBase - and it works ok, but the interrupt load on the PIC microcontroller is very high and limits what else the MiniBase can be doing - so now I’m planning on just biting the bullet and adding a fifth wire to the CAN+Power connector.

 

And you’re right, I forgot to include the protocol messages sent back to the host computer in the list.  Which at the moment is just the switch event:

<< Switch (10CSSSS) (sssssss)

I’m not sure I’ve ever seen iTrain software send a Switch Request.

 

The other thing I didn’t mention is that the PWM daughterboard has the circuitry for detecting block occupancy (using a low-side sense resistor, op-amp and PIC A/D) for each channel, and also sends feedback messages to iTrain using the 0b10 “switch” event.  Hopefully that means I can have blocks with less critical stopping points (ie, not stations) that won’t need TCS sensors at all.

 

 

[Melandir]

Hi mrp

 

It's good to know that your project is going strong, just a dumb question from a dcc point of view.

I can have DCC take care of automating the turnouts and DCC block detection to know the train position and feedback (Railcom) and report anything to the PC, what I really missing is a system that could drive signals (and ofc Japanese signals)

 

Is it possible to use your system to pilot signal lights only scrapping all the stuff that will be managed by DCC? (I'll need ofc your japanese signals, it's impossible to find good Jap signals on sale at a decent price)

Edited January 26, 2015 by Melandir

[mrp]

Hi Melandir,

 

I guess it would depend what automation software you’re using.

 

For example, iTrain Pro is designed to work with multiple “interfaces” at the same time.

 

This is for exactly the case you describe, where you want to control most things using DCC, but want to automate signals and/or feedbacks using a separate device.

 

My system currently uses the “Dinamo (RMU)” interface over a USB serial port.  To do what you describe, you might configure Interface ‘1’ as LocoNet (or whatever DCC Control Station you are using) and Interface ‘2’ as Dinamo - each using different USB serial ports.

 

Then, for each Signal you define, the properties page allows you to select which Interface, Device and Address it is using.

 

That’s how it works for iTrain.  I guess other automation software would be similar.

 

But I haven’t tried any of this yet, so I’m just describing what I’ve read in the documentation.

[kvp]

I think railcom means the feedback is taken care of. An alternative soltution would be to make a custom DCC decoder that can take extended accessory commands and output the 4 wire protocol the current signals use, so one decoder could process commands for multiple signals hanging on the same bus. This would mean the system could even be run without a pc and would be compatible with any centrals and switchboards that support extended (signal) packets. It might be possible to add a DCC input board to the current stack and use the base board to drive the signals.

Edited January 26, 2015 by kvp

[Melandir]

Hi mrp,

 

My dcc command station (z21) talk with the PC using the normal LAN and I can use an usb port to pilot the lights,

I use Itrain as a control program so your system really interest me.

[mrp]

Hello All,

 

A bit more progress to report.  I managed to get the PWM outputs synchronized across MiniBase boards without needing an extra wire (by using the CAN signal).  To test it I knocked up something I’ve been wanting to do for a while - automated track cleaning.  Just load up the fluid and step back…

 

 

Here’s the track plan I’m using for development and testing.  It has nine isolated PWM blocks and nine automated turnouts.  Plus four TCS sensors.

 

 

[kvp]

Great! Just two questions: Do you use chopped (power/coast) or push-pull (power/brake) PWM? Also how did you solve the problem with can signals only?

[mrp]

Hi kvp,

 

Currently I’m using push-pull.  I’d prefer to use chopped - less power draw, maybe easier on the motors, less abrupt speed changes - but what I found is that the direction dependent Tomix CL lighting doesn’t work correctly.  The reverse voltage from the motor is enough to turn on the lights in the wrong direction, so you get both the headlights and tail-lights always on.  I checked the signal from my N-1000-CL on a scope, and it looks like Tomix use push-pull in their own controllers.  With my PWM board I can change it back and forth in software (I'm using the PIC16F1708 with PPS Peripheral Pin Select on the PWM outputs) so I might experiment with configuring it differently depending on the locomotive.

 

Regarding the synchronization - well, it’s a bit of a hack.  One MiniBase acts as a synchronization source.  Once every second, it sends a CAN broadcast message telling all the other boards that a sync sequence is starting, then it sends a sequence of pulses from it’s own 21KHz PWM over the CAN bus (which is clearly a completely invalid CAN message!).  The other boards are waiting for this sequence, and use PIC Input Capture to measure frequency and phase offset, then adjust their own PWM using that.  I’m using a 1024 sample DMA buffer to drive the PWM period, so I can fine tune the frequency fairly accurately without using interrupts (which was my previous problem).  Because CAN retries any transmission errors, even if the 21KHz pulse somehow make their way through to the CAN receiver you still don’t lose any packets.

 

Here’s a video of the PWM from two boards initially free running, then syncing up when I toggle the sync setting about 5 seconds in:-

 

[kvp]

 

Currently I’m using push-pull. I’d prefer to use chopped - less power draw, maybe easier on the motors, less abrupt speed changes - but what I found is that the direction dependent Tomix CL lighting doesn’t work correctly. The reverse voltage from the motor is enough to turn on the lights in the wrong direction, so you get both the headlights and tail-lights always on. I checked the signal from my N-1000-CL on a scope, and it looks like Tomix use push-pull in their own controllers.

This problem happens when the tri state mode in the chips lets loose both outputs. If the outputs are disconnected, but the free wheeling diodes are still connected with the right polarity, then the diodes clip the backemf, while still leaving the drive outputs disconnected. The push pull system has the bad habit of turning completly on and off the coils, so instead of just clipping the exess backemf, the motor is actively braked. This makes them rather hot and damages the motors in the long run. So choosing the right drive chip or adding the diodes externally can help a lot. I've made a L293D based circuit that does exactly this and it works fine with CL equipped trains.

 

 

Regarding the synchronization - well, it’s a bit of a hack. 

It's a nice one and an original solution. Very similar like how zero stretching was hacked into the DCC protocol. Can this protocol extenstion be used to synchronize DCC command sequences?

[mrp]

Hi kvp,

 

At the moment I’m using the L6225, but for the next board revision I want to try out the Toshiba TB6612FNG (it’s a newer cheaper SMD design with lower on resistance and rated to 100KHz PWM).  I’m using the L293DD for driving points/turnouts, but avoided it for PWM since it doesn’t run very well over about 5KHz and has quite a high voltage drop.

 

What PWM frequency are you using?  Is it possible that the lack of back EMF you’re seeing is just an artifact of the very slow L293D switching speed and relatively high on resistance?  I guess I don’t really see how the diode configuration would help - I would have thought that the back EMF would show up as a reverse voltage between OUT1 and OUT2 with neither output necessarily lower or high than GND and VS.  Anyway, not a subject I’m all that familiar with…

 

On the plus side, my PWM signal looks the same on the scope as the signal from the Tomix controller, so at least in theory it shouldn’t be overheating or damaging the motors any more than the official product!

 

I don’t know enough about DCC to comment.  One thing that helped in my case is I’m writing both ends of the protocol, so I can program the CAN receiver to expect and/or ignore the non-CAN sequence of PWM pulses.  I’m not sure that sending a burst of 21KHz PWM pulses to an off-the-shelf CAN decoder would be a great move.  Isn’t that the same scenario where Tomix CL lighting is rumoured to fry some brands of decoder?

 

For the MiniBase, I’m using the dsPIC33EP64GP504.  That lets me use PPS to disconnect the CAN transmitter from its output pin and then route the PWM output to that same pin.  It also lets me route the CAN receive pin to the Input Capture module, and to disconnect the pin from CAN to avoid packet errors during the sync pulses.

[kvp]

What PWM frequency are you using? Is it possible that the lack of back EMF you’re seeing is just an artifact of the very slow L293D switching speed and relatively high on resistance? I guess I don’t really see how the diode configuration would help - I would have thought that the back EMF would show up as a reverse voltage between OUT1 and OUT2 with neither output necessarily lower or high than GND and VS. Anyway, not a subject I’m all that familiar with.

 

I got backemf spikes with 50, 100 and 1000 Hz, so it's mostly frequency independent. The trick is that the backemf show as a negative voltage relative to ground if you don't disconnect both outputs. Then this voltage can be clamped to -0.3V with the right diodes by creating a current loop through the diodes. No active braking is done, so no power is taken out through the supply ground but the motor's backemf voltage is kept below the turn on voltage of the leds. The trick is to actively switch the enable of the powered output only, independently to the enable of the ground output. (the two switch places when you reverse the direction) This can be done with any dual H bridge driver, so i only used the cheap and weak L293D as it was available in a parts shop within 5 minutes of walking from my workplace. This should work with any high performance driver ic that has independent output enable lines or contain the right logic to handle it internally.

 

On the plus side, my PWM signal looks the same on the scope as the signal from the Tomix controller, so at least in theory it shouldn’t be overheating or damaging the motors any more than the official product!

 

Check the currents too. Getting the same voltage values with much higher currents is imho not a good idea. (this is why it's not a good idea to use audio opamps for driving motors, they work, but the currents are much higher and more power is wasted as heat)

 

I'm not good with the CAN bus to tell if you can fry or not your inputs with the PWM pulses, but as long as both protocols are at TTL level, there should be no problems. The Tomix CL and DCC decoder problem has more to do with the voltage sampler ADC-s in certain DCC decoders, that don't like high voltage, high current pulses on their tiny sampling capacitor. DCC itself is around the same frequency, but the CL pulses are much narrower and more free wheeling, giving a higher frequency and the relatively slow diode bridges in the decoders can't keep up with and this can result in negative voltages on the analog input pins. A properly ESD protected decoder can run on an analog CL system without getting fried. Actually my el cheapo Fleischmann decoders do exactly this, they run just fine in analog conversion mode with a low to medium frequencly CL PWM controller. Of course i usually keep the effective CL frequency below the DCC frequency to be safe with less solid decoders.

 

For DCC operation, you would need not only phase synchron, but time synchron too, because it's a bipolar pulse width modulated serial protocol. For that, a single PWM pulse should be enough or a common time marker has to be triggered at the same time. Xpressnet and Loconet gets around this by providing a differential reference stream on the two outer conductors of their serial cables. Those cables carry the master copy of the track signal, so the inner protocol doesn't matter for the boosters. Some systems supporting SX and other trinary protocols carry single ended multibit track signals with a common ground in a 5 wire connector. (usually it's power, polarity, enable, ground and an open collector fault input)

[mrp]

Hi kvp,

 

I see what you’re saying, but I don’t understand how what you’re describing is any different from normal non-tristate operation - what’s described as “low-side slow decay” in this diagram.

 

 

Say during the drive phase switches (1) and (4) are on, then xOUTA will be +ve and xOUTB will be -ve.  During the decay phase the motor will be generating and the polarities will reverse (xOUTA will be -ve and xOUTB +ve), so the low-side decay path will be through switch (4) and the flyback diode across switch (3).

 

If you don’t turn on switch (4), you won’t get slow decay.  And I wouldn’t have thought switch (3) would have any effect since it’s not part of the decay path.  I guess I don’t see how tri-stating (1) and turning on (3) and (4) is much different from just tri-stating (1) and turning on (4).

 

Anyway, none of the motor driver chips that I’m working with (L298, L6202, L6225, TB6612, A3966) let you independently control each switch in the low-side decay loop.  Generally, they all have just the In1, In2 and Enable inputs.  I think that for me to try out what you describe I’d need to build the H-bridge out of two Half-H drivers (like the L293D)?

 

Edit: I forgot to mention - in my circuit, the PIC is driving the CAN bus using 3.3V logic levels via a MCP2562 CAN transceiver, which converts the signal to 5V differential needed for the bus.  When I send the PWM signal, I’m sending it as 3.3V logic to the transceiver, so I’m driving the bus at normal CAN differential voltage levels.  The only thing I need to watch out for is that CAN transceivers generally have permanent dominant detection and will disable the bus if you try to assert Txd for more than about 1.25ms.

 

Another edit:  Correct me if I’m wrong, but I don’t think the Tomix CL lighting design will work very well for PWM frequencies below about 2000 Hz.  The MLCC capacitor they use is only 1uF, which by my calculation - with the 560Ω current limiting resistor - gives a discharge time of about 0.5 ms.

Edited February 16, 2015 by mrp

[kvp]

 

If you don’t turn on switch (4), you won’t get slow decay. And I wouldn’t have thought switch (3) would have any effect since it’s not part of the decay path. I guess I don’t see how tri-stating (1) and turning on (3) and (4) is much different from just tri-stating (1) and turning on (4).

The trick is that the diode only allows current from ground towards the motor. Opening transistor 3 allows a counter current from the motor side towards earth, which can be stronger, so in this case current will flow from both sides of the motor towards ground, until any capacitance is discharged, then the backemf voltage can take over. Backemf is overlaid on any static capacitance, and while it has to be clipped with the diodes, imho the carged up capacitance in the system (feeds, rails, motor and lighting filters) should not be discharged. Also the counter current could effectively brake the motor if it's large enough.

 

 

I think that for me to try out what you describe I’d need to build the H-bridge out of two Half-H drivers (like the L293D)?

Or just use two chips for the tests. If it gives better results, you can still switch to a chip with 2 enable inputs or one with the switching pattern built into it's drive logic. I think there are drive chips that only have 2 inputs, with the following pattern: 00:brake, 01:forwards, 10:backwards, 11:free wheeling.

 

I use both low and high side slow decay depending on direction as it's easier to implement and this has eliminated headlight flicker while keeping the motors cooler and the capacitors charged.

 

 

Correct me if I’m wrong, but I don’t think the Tomix CL lighting design will work very well for PWM frequencies below about 2000 Hz. The MLCC capacitor they use is only 1uF, which by my calculation - with the 560Ω current limiting resistor - gives a discharge time of about 0.5 ms.

Yes, but since i made my first PWM CL drive for a Z scale Maerklin locomotive (made for them by a Hong Kong company) this was not a problem. That loco has a larger cap, so runs well with a 100 Hz PWM signal. The funny thing is that Maerklin never announced the CL lights or made a controller that actually supports it, but it's there and the two 5 micro led panels look completly space age compared to the grain of rice bulbs Maerklin was using back then on other locomotives.

 

Also leds have a visible on time and a saturation time, which means if you make it flicker at high frequencies but with full voltages, you will see a continously lit led. All passive LED matrix displays use this. Also there is a certain On percentage, where you won't effectively see more brightness if you increase the On time further. The cause is that the percived brightness of led's are not fully linear. Rokuhan uses a trick in their PWM controller, where the base PWM and CL frequency is the same, so they are using a high frequency drive to control both the CL system and the motors with a single knob. The same high frequency drive is also used in DCC decoders. Some manufacturers even allow setting the PWM frequency between 50 Hz and 32 kHz. So far the highest frequency drive i've made was 1953 Hz (1 mips / 512 with a pic12f510) and it works fine. (if maybe not 100% flicker free) I'll have to investigate this further (including using a stronger drive chip) as soon as i get my current DCC club project out through the door.

[mrp]

...so in this case current will flow from both sides of the motor towards ground, until any capacitance is discharged, then the backemf voltage can take over.

 

Yeah - I was going to comment on the capacitance, but I didn’t think it would actually make that much difference.  As you say, switch (3) only has any effect while the voltage at xOUTA is positive - which is while the capacitance in the system is keeping the reverse EMF above ground.  I guess I need to wire up a test circuit to a scope sometime and see if there’s any visible difference.

I use both low and high side slow decay depending on direction as it's easier to implement and this has eliminated headlight flicker while keeping the motors cooler and the capacitors charged.

 

Well, I would say I’m already doing that as well.  It’s just that my low/high side slow decay isn’t tri-stating the opposite side switch (since that switch is automatically turned on by the motor driver’s internal logic).  The question is really whether it’s worth the extra effort to tri-state that additional switch.