I'm liking the idea of stacking a second motor shield on top of the existing motor shield. I bought a Seeed motor shield that has an L298 with a nice size heat sink. By bending out the relevant pins I can isolate them from the lower shield and wire wrap them to the corresponding pins. I will need to add one wire to pick up one signal not on a board pin. I'm also considering wiring the two output stages in parallel per directions on the L298 data sheet. If that works then I might try wiring the second motor shield board in parallel with the track power driver. I will need to see if the circuitry can essentially drive 3 channels. I will also replace the current sense resistor with a Hall sensor. I would be happy to get 5 amps from this lashup.
Dave, Your test results don't put a smile on my face, but I sure am glad you took the time to do them. I hope you find some H-Bridge units that can handle the higher loads.
If one was to plug a motor shield into a breadboard using cat 5 wire (24 awg wire) the voltage drop at 20 feet from 5.0v is 0.021v leaving 4.979v of signal. You could use one mega 256 and 2 or more motor shields and feed the 2nd, 3rd, etc.. 20 feet away. You may need a buffer ic (logic amplifier) to split the signals and still have enough power to run the remote shields. The 8 wires in a cat 5 cable are enough to send 2 control lines, 2 dcc signal lines, 1 ground, 1 +5v, 2 current sense returns back. 40 feet would be 4.959 volts starting with 5.0v. The one problem may be the voltage of the sense lines coming back and their voltage drop.
The issue with more than one shield is whether the pin driving circuits have sufficient power. DCC is a relatively slow digital signal but I would be leery of sending it long distances. I will try to try my idea this weekend.
What is the advantage of using 8 wires to mount the Mega remotely rather than sending two bus wires from a second local Mega?
Sending any bus spi, i2c, can, serial, means puting a "message" on the wire(s). Sending a message or data usually means forming a packet of data, sending data, reciving data, unpacking data, etc... Using the 8 wires from a cat 5 is same as the pins (is there voltage there yes or no). For something like the HHT you need to send data, for a motor shield it just on and off signals.
If you are only operating a standalone motor shield and a master Arduino is controlling its enable pins, reading back the current, etc, then you would only need to send and receive these signals, as opposed to sending data (via serial or another method). A few weeks ago we were discussing the ability to utilize multiple arduinos so you can effectively have more output <z> pins and more input <Q> sensors. This is what triggered the discussion about using i2c or some other method to have a master Arduino communicate with auxiliary Arduinos. My thinking was to combine all of the recent ideas - e.g. how to build a power district using another motor shield, how to use the Arduino as an auto reverser, and how to operate a remote Arduino through commands controlled by a master - into a style of "auxiliary base station" that would run a modified form the of base station software designed as a "server." To do so requires sending both a master DCC signal and a set of serial-style commands to the aux base stations. This can be done directly by (1) long wires from pin 12 on the master Arduino to some other pins on multiple other aux base stations, and (2) long wires from the i2c bus of the master Arduino to the i2c busses of the the aux Arduinos. In principle, this is all you need. But if the long wires prove to be too noisy, you get interference, etc., then we need to convert these signals to something else at the source, and "unconvert" them at the destination. One possibility is to use an RS485 protocol, but that is only one of many. It may be that the noise and interference is actually not a problem at all.
Tying together the two outputs of the Arduino motor shield is a great idea and allowed per the l298 specs. This would be an easy way to potentially double the current capacity. We would then need a separate board to create the prog track signal. An aux base station (per above) would be helpful in this context.
Geez, you step away for a day and the posts get away from you! I can only really weigh in on the RS485, since I started it. There are a bunch of RS485 transceiver IC's out there that can fit the bill. I am looking at the TI SN65LBC184DR for it's robust design and transient voltage suppression protection. Looks like a good option for something that is exposed to constant connection/disconnection (physically). The beauty of these IC's is it's basically take the TTL serial TX/RX lines from the Arduino and it translates it to/from RS485 for the buss side. Utilizing an RJ45 connection standard will give us plenty of lines for the RS485 A and B buss lines, ground and I suggest a +12VDC buss voltage. Let the END USER devices regulate the +12V down to the required voltage. Trying to pipe a regulated +5VDC down the line will result in too much voltage drop. Even a good LDO regulator will have a tough time with this to get a good +3.3VDC. +5VDC is out of the question. Good system design includes resources for adaptation. For the L298 design, I have a first revision board on my bench as I type this in testing. I am running into a problem with the loco not responding to commands. I have good DCC signal to the track, but I'm curious about the 18Vp-p level. Can anyone with a working setup look at their DCC++ signal with a scope and tell me what they are seeing? I'm running a 12VDC power supply to the shield. I expected to see a negative voltage swing for when the channel switches polarity, but so far I'm only seeing ground to positive. This is PROBABLY because I am only probing one side of the channel, without ground. If I connect the ground to the other side of the channel, the waveform drops by half, get's very noisy and the L298 starts emitting a buzz. I never saw this years ago with my homemade setup, so this was a new one on me. Here is the latest scope on the main channel:
Gregg, Include the AR in the above list and you have my entire wish list covered. Thank you! In light of Dave Bodnar's test results I'm considering an Arduino motor shield powering the blocks adjoining the reversing section and the two Pololu shields to power the rest of the layout. Dave
One thing to note about the RS485 bus is that even though the standard supports the idea of multiple-to-multiple communication, this is only from the perspective of electrical connectivity. The two wires that make up the bus provide just a single path for a digital signal. At each drop point the user can select to be in "receive" mode or "transmit" mode. More than one device can be in receive mode at the same time, and a protection circuit usually keeps the line quiet if everyone goes into receive mode at the same time, but only one device can be in transmit mode at any given time. Most TTL-RS485 converters can be connected directly to the transmit and receive lines of a serial bus, and a lot of the Arduino demos show exactly that. HOWEVER... the demos don't show that you can't simply send and receive text using this method as you would normally do with a serial-to-serial connection. This is because serial devices have two distinct lines --- transmit and receive. It is full duplex -- the transmit output of one device connects to the receive input of the other, and vice-versa. RS485 is normally half-duplex. In the demos showing this work, you normally see the first Arduino set the RS485 to transmit, then it sends a serial "Hello World" to the other Arduino. And then, most importantly, it sets its RS485 back to receive mode immediately. In the meantime, the other Arduino was originally set to receive mode, and once it receives its message it can respond by setting its RS485 to transmit mode. The changing of RS485s from transmit to receive and back again needs to be coordinated, and thus requires a master Arduino to basically "conduct" the whole network. These are the additional commands that will be added to DCC++ (this has nothing to do with the transmission of a master DCC signal to drive the motor shield --- only the serial communication of DCC++ commands).
[QUOTE="KE4NYV, post: 959337 Can anyone with a working setup look at their DCC++ signal with a scope and tell me what they are seeing? I'm running a 12VDC power supply to the shield. I expected to see a negative voltage swing for when the channel switches polarity, but so far I'm only seeing ground to positive. This is PROBABLY because I am only probing one side of the channel, without ground. If I connect the ground to the other side of the channel, the waveform drops by half, get's very noisy and the L298 starts emitting a buzz. I never saw this years ago with my homemade setup, so this was a new one on me. Here is the latest scope on the main channel: [/QUOTE] To get a good reading I had to disconnect the USB and my bench power supply and run the whole thing on batteries - otherwise I got nasty wave forms, probably due to a grounding issue between the controller and the PC and/or power supply. Here are two images that I got from my scope: Hope that helps. dave
Someone was talking about just stacking motor shields on top of one another to do districts. I was offering a way to do that and remap the lines without a second arduino with just wires and a buffer ic. Almost all the buses are single master muti slave bus, the only one i can think of off the top of my head that is multi master is can bus like used in cars and factories.
I completely agree --- if all you want are districts you don't need any other Arduinos. Motor shields can operate standalone provided they get digital power. As you noted, you can then run a cat-5 cable from the master Arduino to each remote shield. Would need to send the DCC signal, two enable signals, and read back the two current sense lines (as well as provide the digital power and ground). If you wanted something more compact, you could stack the shields, which means that digital power and the DCC signal is ready to go, but would need to bend the enable and current sense pins out of the way so you can jumper them to other pins. Same principle, different physical layout. The solution I suggested is to address more than just power districts, but rather when you actually need additional Arudinos (either with or without their own motor shields). Of course the best thing is to have a lot of options, since there are so many ways to address the same problem. For me, that's what makes this so fun!
I don't currently need a auto reverse but i would probably look at a uno or mini with a block detector (ir, sonic, rfid, etc...) set at max train lenght away from the loop, have it set the switch points to the track to the direction you want to go in then at the end of the loop have another detector switch the points back flip the polarity and exit the loop as it passes the inbound sensor going out it could reset the loop for the next pass. the key would be to reverse the polarity while on the track so its the same as the main track going out, not trying to reverse while going across it.
Come to think of it you could use a single motor shield to do this, just use output A as the going in output after the sense A sees a train in its district wait 5 sec then disable output A and enable Output B, once the sense B shows no current, reverse the enable pins back to where it started. Making sure that both A and B outputs can NOT be enabled at the same time. You would have to wire the outputs so A+ and B- would both go to one side of the track, and A- and B+ both went to the other side of the track, insulate this loop from the Y (so the Y is the same as the main track). You would also need to align the A side to match the main track going in.
Just did that and I'm the second responder. I think it is a great idea. I'm reluctant to ask questions to the present forum. You folks are so involved in the hardware and software issues to improve this great system so I don't want to bother you with my newbie problems. David
David, Are your questions specific to DCC++ Arduino applications or hardware? Or are they more generic? If they aren't specific to DCC++, why not start a new thread for your question(s)? If it is DCC++ specific, or if you aren't sure, ask away here.
For the time being the suggestion is to create new threads with "DCC++" at the start of the subject line. If we do that and the staff does ultimately create a DCC++ subforum, the threads can be easily moved. (I'll just have to change my Favorites link to the Forum rather than this thread. I think I can manage that ).
