JohnGaltLine posted:Yes, the RS485 standard only needs 2 wires for communication (just like RS232 or I2C), but it also needs a common ground between devices... a third wire.
No it doesn't. It is a differential signal, so it does not need a common ground. I have an RS485 bus setup right now between my Raspberry Pi and Arduino and they don't share a common ground and work perfectly. Besides even if you did. You stated that you are going to use an ATX power supply to power all your Aduinos, so they would already have a common ground.
JohnGaltLine posted:It would depend what your design goals are to come up with a plan of attack for servo control. for easy to program and hook up, an array of Arduino-type boards would probably do the job, where as for a lower cost solution one uP might be used to control many simpler PWM drives for the servos. I'd have to really get into the thing to figure out what way I'd go. As far as connecting to Legacy, I think JMRi will do much of this for you, but it is also pretty easy to have the uP read commands directly from the serial port.
Will I'm planning on using a CMRI library for Arduino that will let me do a lot with JMRI attached. One reason would be prototypical signals, where JMRI would handle the logic. The reason for Legacy is because I would mostly throw the turnouts with the CAB-2 than JMRI. JMRI functionality is just there if I want it.
JohnGaltLine posted:I'm using the same port extender in another project I'm working on (Here), but I'm buying mine shipped out of China for about 80 cents each. I haven't researched the hysteresis of these chips to see if they require a Schmitt trigger for a solid IO or if they do it on their own as the project I planed to use them in is only dealing with solid highs and lows. I'll post back here if I find out one way or the other.
I didn't have time to look at your other post regarding the IO expander, but I buy them from Adafruit and currently have three of them in my parts box. I like buying from Adafruit even if I pay a little more, because they provide a lot of free information and libraries for Arduino and Raspberry Pi. I think I would still put a schmitt trigger just to debounce the signal. They would be perfectly fine reading high and low of a digital signal. Adafruit's library would take care of all the heavy lifting. Check it out. It has digitalRead function, so all you have to do in the sketch is mcp.digitalRead(0) for example.
JohnGaltLine posted:"I think I will use the schmitt trigger eliminate code in my program since it will be doing a lot of other tasks. " In this case one has nothing to do with the other. The purpose of the Schmitt trigger is to allow the processor to have a clearly defined high or low state that does not fluctuate back and forth when the signal is in transition between states. (As an example [with approximate values] in most logic gates anything below 1 volt is low and and anything over 3 volts is high. The problem comes in that the area between 1 and 3 volts is undefined and the state can float between values at that voltage. The schmitt trigger works by saying 'I won't change states until the input voltage reaches a threshold level, well beyond what is certainly a high or low. Basically it filters varying voltage, jittery inputs into strict 1's and 0's. Anyway, the point of all this is, the input pins on an Arduino have Schmitt triggers built in so you don't need to add them if a pin is connected directly to.
I personally think one does have to with the other. If you are trying to run multiple servos, turnout signaling, touch toggles, and whatever else there has to be some limit to what you put into the software side. I much rather use a schmitt trigger on and not have to worry about missing a train in the non-derail "block". Besides the software can get tied up and eventually miss the train in the non-derail block. I use Object Oriented Programming for most of my "complex" stuff, so I can multitask the board. I would still do this if there was a schmitt trigger, so the train would never be missed.
JohnGaltLine posted:And finally, "JGL are you using 5v ground for detection or 18v AC?" I believe JohnF is using track AC (18VAC?) to trigger his set up. I am planning to use 12VDC here. My plan is to use the 12VDC line on an ATX power supply to provide the current for the sensing. The power supply's ground would be connected to track common and the 12+ would connect to the positive power connection on the input board. When an insulated rail is bridged it will conduct the ground path to complete the 12V circuit. I think 5V would probably work, but I expect that 12V will hold up better to losses from distance, track resistance, and dirty wheels and track. The Optocouplers I'm using, with a 1.5K Ohm resistor will work with voltages up to 30VDC (probably 24-28VAC RMS shouldn't cause any damage, but I'm gonna play it safe and say 21VAC for the limit). I've tested the inputs to work just fine at 5 volts as well, but will need to double check this with other optocouplers. I'm using the cny17-1 right now, because I have a bag full of them. Based on the data sheets I see no reason that any of the others I've looked at wouldn't work just as well.
Basically all you're doing is using an insulated rail to light up a single LED. If you can do that, replace the LED with the optocoupler, and you have an isolated, logic level, signal your microprocessor can use. The microprocessor has plenty of time to debounce any flicker from dirty wheels or what-have-you, so hardware debouncing is not needed.
Interesting. Just shows there are 20 ways to do something. I think I much rather use DC myself, because it would make life a little easier, especially since I will be using an ATX power supply anyway. I'm not sure what would be better. A 12V or 5V line. Would it matter, since you are just using the power to complete the circuit? Really the ground (current) is what the train passes to the Optamp. I don't know the answer to this. Just putting it out there. I'm just wondering if there some advantage of using track power or DC.
Professor Chaos posted:If you debounce in software, you should think about an integrating algorithm rather than a simple timed debounce.
I found that response time was too long when I relied on a simple debounce algorithm, which is why I reverted to analog. (I originally went analog because my first microcontroller was a Basic Stamp, which had something like 20 bytes of RAM.)
An RC debounce can effectively discriminate between a momentary loss of contact due to dirty track, versus when the last little bit of wheel has left the sensor rail. An integrating algorithm can emulate that effect.
Yes, I agree with this. I much rather just use the RC Circuit with schmitt trigger than try to write some integrating algorithm in the software to handle this.
