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.
I don't see why a timed debounce would behave any differently than an RC circuit. In one you adjust a variable for how long you want to wait before a state change occurs and in the other you tune the values of the resistor and capacitor to get the same result. After a change in the input state some amount of time passes before that change is registered. Assuming the uP you choose has enough speed to keep up, and you have the free space in memory, the net effect is the same. Either method works equally well, but when timing is not critical, ex 1 or 2 milliseconds won't matter, such as reading an insulated rail or push button, I choose not to add any parts or board space where 4 or 5 lines of code will do the job, and I gain the ability to fine tune the timing down to the millisecond.
Now an RC debounce will behave a little differently than the software solution I typically use, however a couple more lines of code could make it behave the same. I actually prefer a uniform timing between on's and off's. The RC design will switch from low to high much quicker than from high to low in a typical configuration. Once again, adding parts can equal this out, but to me code is more economical than parts.
On the RS485, every example I've seen and all the documentation I've seen shows some common ground. Most just use a third wire while many industrial applications use earth ground. In any case it doesn't matter to me as it will only be two wires between devices and track common will be connected to them anyway.
On the port expander there's two things. I do tend to purchase products from vendors I support for developing something I use, but for a single component a 2.5 to 5x markup seems a bit much. LadyA can have my money for new products, not components. The other issue is library overhead. Does the library for this chip also require the wire library to be included, or will it work as a standalone? If a standalone library, if it's smaller than the wire library I may look at it. If it requires the wire library as well then it's a toss up depending on free space.
As a third thing, the port expander chip is nice because it's easy to use if you need to add just a couple of both inputs and outputs, however using shift registers is usually a better way to go if you need a large numbers of I/O. there are also many other options for port expander chips out there using both I2C and SPI. If you're comfortable with SMT parts, 64 bit expanders are reasonably priced.
Crood58 posted: " 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. "
I think maybe some terms are getting confused or something. Adding a Schmitt trigger will have no effect on the code needed, it will simply allow the processor to have an absolute high/low, one/zero state. it is an unneeded part if you're input is connected directly to an Arduino as the ATmel chip that is the brains in an Arduino has Schmitt triggers built in on all GPIO pins.
A Schmitt trigger does not store any data. it will report whatever the current value is when the input is polled it just filters incoming signals that may have some ripple or noise into nice clean square waves. The use of Schmitt triggers was suggested earlier i the thread to filter out noise from varying saturation of the optocoupler that may have caused problems when connected to the 74165 shift registers for input as these have a no-mans-land- where the state can be undefined.
If you're really worried about ensuring that a train triggers an anti-derail as close to instantly as possible, the input should be connected to one of the Arduino's hardware interrupt pins. The mcp23017 also supports interrupts. For me I don't see the point. Even with a rather complex sketch an arduino is likely to make a full run through the loop several thousand times each second. There's no real world difference to me between a relay clicking on 1/10,000th of a second after the engine touches the insulated rail and it taking 1/1,000th of a second. In the real world whether using a hardware or software method to debounce the inputs, transition times of 15 to 30 milliseconds are going to be the norm, so I don't think it matters if the uP takes 1 or 2 ms to react. For reference of the reaction times here, an O scale train moving at a scale speed of Two-hundred MPH will move about 0.07 inches in a millisecond. I would be doubtful the contacts of the relay can close or the solenoid or servo throwing the switch can move the points before the Arduino has had a thousand times to check the state of the input. The Songle relays on the module boards are specked to take up to 10ms to click on, for example.
" 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. "
It is not really going to matter all that much here, but higher voltages withstand longer distances better and AC better than DC. I don't know that it will actually matter with the low current needed to drive an optocoupler but I have the 12v rail doing nothing so that's what I plan to use it for. For folks using a wall wart to power the electronics, just using track power for triggering might be easier to do. you don't have to worry about any new power supply if you don't want to. The only difference in design if one re-did it to only work with DC would be removing a diode that costs less than 1/10th of a penny from each input (Just bought a sack of 1000 1n4007's for $7.)
All told My purpose with the various designs I'v proposed in this and other similar threads is to make the device as easy for the lay-person to build as possible while still keeping costs down well below any store-bought solution. Sometime a choice was made that raised the cost to greatly simplify the design. other times some complexity was added to drop the cost. I'm still not 100% sure on things, but it looks like using a Mega2560 with just a couple added components seems to make more sense than having to add 10 more chips for the same functionality. It costs about $4 more, but seems worth it to make things simple. (On the other hand it actually would cost less if one was paying boutique electronics parts prices. ex $2.75 for a 3-pack of shift registers from Adafruit vs 95 cents for 10 from the auction site.(even less if you buy more.) )
JGL
