@Keith Ledbetter suggested that we start threads for different sections of the DCC++ EX project, so here we go on the hardware thread. This is intended for development of hardware, including the original setups plus talk about other solutions, including Raspberry Pi HATs, standalone boosters, etc. I'll start it off with my custom RPi HAT work. I want to first pass a sanity check with the members of the group here. How is this looking? By no way do I want to limit this thread to Raspberry Pi discussion. This is open to all hardware solutions, no matter the stage of development. I anticipate working on several other variants of hardware, my board design skills are always available if you've got a good idea.
I'm reconsidering motor chips - here's some options Stick with the currently designed pololu motor driver (MC33926) and get 3A continuous supply on both the main line and the programming line Go for a higher current motor driver like the VNH5019, which will give us 12A continuous power on the main line, and use an MC33926 on the programming track. Keep the big and small motor driver pair concept, but use a different combination of motor driver chips. Suggestions?
just remember, whatever motor driver you use, your current sensing must be accurate, and with good low-amp resolution on the programming track. with that said, i am favorable now to producing the main DCC++ signal at low current, and using high-amp boosters around the layout, where needed. my thinking on this has evolved from my original use of a IBT-2 motor board, with 40A output. once the signal is out on the layout, every booster has signal, and can power it's section of the layout. so if a track short-circuit happens, the whole layout will not die. just my 2-cents. ~Travis
What is the current sensing response with the 470nF (C3, C4) capacitors in the current sensing path? For programming track you need raise times in the order of 0.1ms to be able to read the 6ms pulses correct. If you want voltage sensing you'd need a voltage divider from the H-Bridge output. From one or with low-drop voltage diodes from both. With custom HW it's as well easy to add 4 NAND to switch from prog to main track signal for the programming (U6) part of the H-bridge. Regards, Harald.
When you are doing a custom motor driver, please look at the rise and fall times of the outgoing DCC pulses. If these are too steep, there might be radio interferences which we want to avoid as a layout is some kind of antenna. We don't want the radio folks to hear us. Regards, Harald.
NMRA spec for the PROG track is a max current of 250mA. You can get away with a DRV8888 or similar for that output. For OPS I would opt for a similar 2-5A h-bridge rather than rely on the Pololu boards due to costs associated with them. Also keep in mind that if you want to support RailCom you will need the ability to short the rails together for the ~487 microseconds of the cut-out period while also reading the data coming back in from the decoders.
Yes, but some sound decoders are greedy and there is a point in being able to run a single locomotive on the prog track without turning a HW switch. So true. Is there any shield that already can do this or do we need to do our own design for that? I think I saw some open source designs for RailCom cutout and detector but I am probably the wrong person to go after RailCom as I have so many old deocders that are upset by RailCom that I will not be able to use that I think. Regards, Harald.
That is true but it would be in violation of NMRA PROG track spec for a command station. That is why you see some PROG track boosters out on the market. You could add a flag or jumper that the user could set on their own and still be in compliance with the defaults (likely) RailCom will require additional circuitry for any shield/h-bridge combination. There are a number of designs out there and even some in the NMRA specs for RailCom. I'm currently using a custom circuit that was designed for a commercial CS product that hasn't been released yet, I have permission from the designer and their input on customizing it for through-hole components.
I am totally for to have the default limit at 250mA like the spec says. But if the hardware had the spec to do a little more ("turbo mode") and that could be enabled with a command and/or pin on the board that would be nice. Nice that you are "in the loop" (oh, sorry, obvious pun ;-) ) on RailCom. Harald.
If we have to short the rails together for a brief moment, can't we just put the H-bridge into "brake" mode and watch the current coming in? To put most H-bridges into brake mode you have to set both of the direction pins "high".... so we would need simply to add another timer-capable pin and drive it opposite of the existing pin except for that brief railcom break.
Yes, that is half of the circuit (short the rails). The second half is the current sense circuit which reads the data coming in against a known current source for compare. In my case I'm using an LM393 with a ~19mA vref. Each h-bridge is different and you would need to check the datasheet for specifics, in the case of the LMD18200 you can do this by setting brake and enable LOW and I believe the L298 is similar. There was a post on here about reading RailCom data with DCC++ and the L298 but I don't know that the specifics were published or not. This can be accomplished on the same timer as long as you have the right resolution. There is also the need to time the cut-out during the preamble bits which lends itself nicely to this as well.
Okay, here's my first go at the schematic for a SAMD21 base station. I've included expansion headers for an LCD, a Railcom expansion board, LCC/Loconet/S88/CMRI, and an ESP8266. Note that the SPI bus on the layout bus expansion header is a SERCOM and can be turned into a multitude of different buses, including UART. What of it is excess, and what am I missing expansion wise? @Atani is the 8266 expansion header ever going to be useful?
DCC++EX uses the ESP8266 connection for WiFi exposure. For the LCC/S88/etc connection, for LCC which pin will be used for the CAN alert pin? For RailCom to work you may need to expose the h-bridge enable pins.
If you're using an LCC expansion you probably won't need the I2C pins, so you can just use those. Any reason that won't work? Can you explain a little more about this? I guess I don't really have a full working understanding of what's going on with railcom just yet.
Are the pins that those are connected to not used for SPI and are they an INT pin on the SMD21? It depends on the h-bridge really. The requirement is that you set the h-bridge into a "coast" mode, which in the case of the LMD18200 or L298 is toggle the BRAKE and ENABLE pins which makes the output pins floating. The outputs should be shorted by the RailCom detector during the cut-out period (~487 microseconds starting halfway through the first preamble bit and ending halfway through the 6th bit, roughly). RailCom detection may be better suited to be directly integrated into the board *IF* it is a priority feature or it can be left off the board and have it added as a dedicated RailCom detector/cut-out device.
Oh wait, I probably can't just say "use the I2C pins" because they might be connected to an LCD. Bad logic on my part. I'll expand the header with two more interrupt pins. I guess I left the railcom detector circuitry off the board because I don't know what the best way to implement it is. My strategy here is to make a separate board for now so I can play with different designs, and integrate it later once I've got the design nailed down. To be clear, my definition of a railcom expansion board is just the circuitry that is listening to the bus. On both motor drivers I have selected, the outputs go into high impedance mode (aka coast mode) when one of the enable pins is turned off. If that is the case, do I ever need to drive both of the "IN" pins high or low at the same time? If not, I can save myself two I/O by putting an inverter on the second "IN" pin. @Atani - any clue here? MC33926:: VNH5019::
For the MC33926 it appears that you can set EN to LOW and have it enter the right state, L298 is the same and LMD18200 is EN=LOW, BRAKE=HIGH. For VNH5019, I'm not certain since the high impedance modes reference VCC/GND which may not be correct. I would suggest having a couple dedicated I2C headers (probably two is sufficient). There are a few designs out there, I would suggest looking at a few (including the one in the spec) as a starting point. You won't need a few pieces of the designs as you can drive it directly from the SMD21 MCU and not needing to detect when a cut-out should be injected by monitoring the DCC stream.
I've been pulling apart the NMRA standard's circuit diagrams, and I think they're starting to make some sense. But what I'm not liking at all is how GND is referenced to one rail of the DCC bus. That sounds screwy to me. It might work if you have a standalone detector that is powered off of the track, but if you're trying to integrate this thing into a base station with GND being referenced to earth, I don't see how that could work properly. https://www.nmra.org/sites/default/files/s-9.3.2_2012_12_10.pdf Any other circuits out there I should be aware of that don't do this?
That doesn't sound right to me either, but that could be the case in some setups *IF* you configure it that way and use a diode to ensure the connectivity as such. There are a number of circuits out there but very few give clear explanation as to the connections from what I've seen.
I agree that makes no sense. My guess to be honest is it's supposed to be negative (-) not ground if it's going to rails but I'm not sure.
