JohnGaltLine posted: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.
Okay, so Professor Chaos has actually built one of these and seems to have no problems with it. Utilizing hardware for the debounce that is and he saying that you need more than just a debounce timer like normally used in Arduino Sketches. My question what is the complexity of the code required compared to just using the schmitt trigger? If I have to write and test complex code to do this than I much rather just do it in hardware and be done with it. There is always multiple ways to do something, but which one requires less resources and is a more practical application.
JohnGaltLine posted: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.
I disagree. I have this working perfectly fine for weeks without a common ground shared. I don't know why tutorials show this, but it maybe just a safety factor. Why would track common be connected to RS485? I don't recommend that at all. I would keep track power & ground separated from 5V DC power. Hence the Optamp.
JohnGaltLine posted: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.
I agree that the price be more than what you can get out of China, but if I place an order for products than I tend to order some components as well. This way I get a bang for my buck with shipping. I'm not going to cry over spending $2 over .80 cents. Where it makes told sense the Arduino boards themselves. Paying $5 from China vs. spending $20. Same with Servos.
The library does depend on the wire library and automatically includes it within the library. Wait, you are going to tell me that you wouldn't use the library because it depends on the wire library? A few lines back you are arguing hardware vs. software debouncing, which proves my point that there has to be some limit on the software side. The wire library isn't going to make or back anything and people use it all the time for I2C communication.
I disagree again on the shift registers. They need three wire communication and are more complex to address. Where I can use the port expander and have easy addressing. I can but 8 chips on a single I2C bus an have 128 additional I/O, which is a lot.
JohnGaltLine posted: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.
I KNOW that the schmitt trigger does not store a state (I don't know how you got that from what I said). What I was saying was that I much rather use the hardware over the software. I would write library that would include the Adafruit MCP23017 library and use it to constantly check all my inputs. By running someLibrary.Update() in the loop. The Arduino can WALK and CHEW gum at the same time by doing this (see here). Meaning that it is multitasking, so it is doing what the library needs to and processing through the loop. I may not need an interrupt.
JohnGaltLine posted:" 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.)
Yes, I would also have 12V rail doing nothing. This might be a good use for it.
Chris
