the MRH Forum

DCC++ shields compared Journals/Blogs
Reply
Active Member 63 posts costin g Active Member 63 posts
costin g

I've discovered just how poor the performance of the default Arduino motor shield in a DCC++ Base Station is and the fact that there are great alternatives out there. Fast forward to the conclusion: skip the L298-based shields and go to the other shield suggested in the documentation ( Pololu MC33926). If somebody has tried out other models and can share the experience, please add to the thread.

Now to the tests. First, the Arduino motor shield, with a L298P on board. I was aware that it was an outdated model but for the price it seemed like a good enough starting point. And it was for a while, until I started having problems with the chip itself, as it was overheating. Adding a huge heat sink and ventilation to the enclosure helped a bit, but it was still struggling to supply my modest layout with power, especially when a Roco loco with onboard camera was on the layout (that loco alone pulls> 1A for a couple of seconds when booting).

So I've measured the input (DC) and output (DCC / AC) voltages and plotted against the current through the shield. The problem becomes obvious this way.

L298P(2).png 

I've stopped measuring at 1.2A, the power loss in the motor shield being more than 6W and the heat sink burning the fingers in the process. The advertised 2A is nowhere in sight

Today I've received the Pololu MC33926 and I've put it through the same test. You can immediately see the difference!

33926(1).png 

The loss is much less than in the L298 chip and it's barely warm to touch, no heat sink even attached to it. No power problems any more either. So it looks like I'm going to keep the Pololu for the layout control and relegate the Arduino shield to a debugging setup.

I'll be testing it further though. One thing that bugs me is that in case of a short, the over-current protection in the Pololu driver kicks in before DCC++ can detect it. Which is good, the effects of the short circuit are smaller this way. But DCC++ and JMRI still see the power as ON and one has to flip the power button twice to bring everything online. Not a big issue, I just don't like the inconsistency between the on-screen and the layout status. The Pololu shield seems to report back the error status on one of the pins so it should be an easy hack to make DCC++ aware of it.

Hope this helps in making an informed decision on what components to use in new projects.

.costin

 
Reply 0
trainzluvr Prolific poster 1,229 posts
trainzluvr

Thanks for drawing attention

Thanks for drawing attention to these issues with L298.

As an aside, other choices for output would be LMD18200T and BTM7752G, both providing 3A or better, though there are no readily available shields so these would need to be assembled on the Arduino proto shield.

 

YouTube channel: Trainz Luvr
Website: Trains Luvr
Reply 0
TrinityJayOne New member 1 post
TrinityJayOne

Pololu far from perfect

I am curious, are you still using the MC33926? I bought one as opposed to the official shield based on this blog, and unfortunately for me it was a waste of money. The "not a big issue" short circuit detection IS in fact a big issue, and I would wager a dealbreaker for many users.

The short circuit breaker trips in 16 microseconds and cannot be bypassed. That is straight from Pololu themselves. Common layout hardware such as auto reversers and frog juicers rely on detecting shorts to operate, but they don't work anywhere near that fast. The shield breaks their functionality because it shuts down the power before they have a chance to work.

Furthermore, the current sensing capabilities of the shield aren't sensitive enough to reliably detect the brief motor pulses necessary for CV readback. In other words, it can't program locos properly. It can write CVs ok, but if you try to read them back it will either tell you the loco isn't there or report a bunch of garbage values.

In summary, if you have reverse loops or powered frogs that are switched automatically, or you want full programming functionality, do not use this shield.
Reply 0
sdcruz Active Member 56 posts
sdcruz

Brilliant post -thanks Costin

Brilliant post -thanks Costin - I was wondering why I was losing up to 5v using the stock standard Motor Shield - will be getting a pololu.

Regards
Shelton
Reply 0
costin g Active Member 63 posts
costin g

Re: TrinityJayOne

Hi,

Sorry for missing this, I didn't spot your question. Yes, I'm still using the shield and it works just fine. With this modification of the code DCC++ BaseStation code:

https://github.com/costing/BaseStation

At power on it tries a few times in quick iterations to bring the power on, to allow the keepalive capacitors to charge. Any short afterwards keeps the power off until explicitly turned back on.

For all these to work you need to connect the SF pin of MC33926 to pin 4 of Arduino, in addition to the other pins as per the documentation.

I don't have any issue reading or programming CVs either.

The only open question is the frog juicers. I'm running a 3-rail system so I don't have any such hardware around. If you manage to find a way around this I'd be curious to hear about it.

Cheers,

.costin
Reply 0
costin g Active Member 63 posts
costin g

Re: Shelton

Just be aware of the power control tricks above. With them the Pololu shield works flawlessly for me.

Cheers,

.costin
Reply 0
sdcruz Active Member 56 posts
sdcruz

Hi Costin I don't use frog

Hi Costin

I don't use frog juicers on my layout so I shouldnt have any issues with shorts.  However someone did post he had problems with the Programming Track, but as you say you don't encounter these issues - so thanks for the update and thanks for the update on the code.

Regards
Shelton
Reply 0
FrightRisk Active Member 39 posts
FrightRisk

Current Sense

Current sense in order to detect an ACK pulse from a decoder it a LOT more complicated than that. The R3 Motorboard handles this just fine, although it is not as linear as we would like it to be. The real issue is the detection routine and settings in the original DCC++ that are being addressed in DCC++EX. Almost any decoder will work by adjusting the last packets sent in the CV read and write routines and adjusting the threshold. The motor board senses the current pulse, the firmware in the base station is missing them.
Reply 0
Reply