FIRST: take advantage of your mentors expertise

[Steven Sigley]

Originally Posted by de_

Imagine if a robot would reboot in a few seconds.

Please. Please make this happen. It'd be a dream come true.

[techhelpbb]

As I have offered with the electronic motor controls and with LinuxBoy's CAN terminators. Anyone that requires a little prototype help with this please let me know.

The issue of sample speed plays to how fast a 'glitch' or transient you can catch. For example let's say that you hit a bump and your D-Link AP radio connector opens up for 1uS. If you happened to take a sample before or after you might not see that happen. It's an effect of taking discrete samples and it's part of quantization.

The idea of holding off capturing huge amounts of data, and limiting the duration of the data you do capture by time is a very good idea. It means that you could sample more frequently during the time you do sample because you suspect you have a problem you definitely want to catch. This also means that you limit the amount of pointless stuff you need to see later.

Also if you have a sample buffer fast enough to collect data very quickly there's nothing stopping you from using it slowly as well if you desire. In that way if you wanted you could still capture all of the voltage you monitor throughout the duration of a match without additional hardware. You just need to be able to adjust the trigger and sample speed.

Yes these terms are all familiar to people that use oscilloscopes.

[de_]

re sampling: I'd thought capturing power line transients might best be done with a custom analog over voltage or under voltage threshold circuit that thats trigger a counter that measures the length of the glitch and stops when the power returns to within normal bounds. The logger gets interrupted and it reads the count. Might need a little distributed PIC to do it. The threshold under voltage or over voltage threshold would be such that could or would cause corruption, hangs or reboots in the CRio and other critical devices. The logger would record a "device Bridge PS undervoltage for X ms" event.

Overvoltage detection would immediately identify situations where the bridge or camera were accidently powered with 12v, both of which happened to us this year. Also our Crio rebooted a number of times, cause never absolutely confirmed.

[techhelpbb]

Originally Posted by de_

re sampling: I'd thought capturing power line transients might best be done with a custom analog over voltage or under voltage threshold circuit that thats trigger a counter that measures the length of the glitch and stops when the power returns to within normal bounds. The logger gets interrupted and it reads the count. Might need a little distributed PIC to do it. The threshold under voltage or over voltage threshold would be such that could or would cause corruption, hangs or reboots in the CRio and other critical devices. The logger would record a "device Bridge PS undervoltage for X ms" event.

Overvoltage detection would immediately identify situations where the bridge or camera were accidently powered with 12v, both of which happened to us this year. Also our Crio rebooted a number of times, cause never absolutely confirmed.

I completely agree.

That's what I already made a set of modules with op-amps that have a voltage reference, a voltage divider and a latch at the output (a latching voltage comparator).

You set them for the voltage you want to consider too high, or too low and when it hits that point the output sets and stays that way till you clear it.

You can feed that output into the cRIO, drive an LED with it, or connect it to something like a relay as a breaker.

The fancy version uses digital pots (R2R ladders) and is actually calibrated and self testing from a small hand held unit I made.

I originally created them because I kept getting told Team 11's robot mounted Jaguar electronic motor controls had power quality issues last year. So I finally got fed up and made something fast enough (and practical to use on a moving robot) to demonstrate the truth or falsehood of the statement. It wasn't true.

Obviously there is a time for the output to transition, so there is a response time, but it's *much* smaller than for a data logger, and approaches the sort of response time you get from an oscilloscope. Really I could actually do this with discrete transistors or on a wafer...but this is a kid's toy.

The reason I didn't set the circuit up to time the length of the glitch is that it's once again a quantization issue. Even if a small cheap PIC looks at the output of the voltage comparator if the glitch is fast enough it just disappears. With the latch you can force a really short glitch to show up...even if your time counter resolution is too low. So what if your counter misrepresents a 0.1uS glitch for something longer? It's still a glitch and it did not slip by.