Trouble Reading Drivers Station Digital Inputs
 

I'm finding that reading the drivers station digital inputs is unreliable. Our switch panel isn't ready yet so I am tying the signal pin of port 8 directly to the +5 pin. This should avoid the lack of a pull up or pull down problem on the digital inputs.

I'm using the iterativeRobot class. When I call the drivers station method I usually get a one value returned but sometimes I get a zero.

I notice that IterativeRobot class is synchronized to the drivers station packet. But the DriversStation access methods all do a GetData() call. It looks like GetData does a wait for a new packet although the comment says that it doesn't.

Has anyone seen this?

Re: Trouble Reading Drivers Station Digital Inputs
 

we had this problem too. the problem is that the driverStation reads the switch as a 1 if the signal has a + voltage and a 0 otherwise. which sounds nice except if it is disconnected, it bounces back and forth between 1 and 0 (blame cosmic rays)

the fix is (sort of) easy, though a little unprofessional
attach a ground wire with a 150ohm-ish resistor(thats what we used) to the signal pin, and have the switch connect the positive pin as normal
this wil cause the voltage to always be negative if the switch is disconnected, and when it is connected, mostly positive

you might want to play around with the resistor ohms to get a good mix


hope that helped

Re: Trouble Reading Drivers Station Digital Inputs
 

Alas, this is not the problem. I'm getting the variable results when the signal is tied to +5. Not just when the switch is open. Tying the signal to +5 should always be a 1. I understand the use of a pull-up/pull_down resister and we will use one when we wire up or control panel. Hard wiring the signal to +5 is what we are doing now, however and we're still getting the problem.

Re: Trouble Reading Drivers Station Digital Inputs
 

This does seem a LOT like the flaoting value problem some teams have experienced--you might want to do a continuity test and make sure the current is actuall getting through everything

You could also use a purely software approach to the problem, though it's a bit hack-ish. Since this is apparently a rare event, you could design a "buffering" system, where you keep track of not only the bit that you are feeding into your system but also a few before and after it. In other words, with the circuit closed, this would normally look like:

111 1 111

Where the value is the middle was the one you were feeding to anything that needed that value. Obviously with the circuit open, this should look like

000 0 000

But if you have an occasionally occurring 0, this could look like

111 0 111

In this case, it's fairly trivial for the algorithm to "bridge the gap" and change the 0 to a 1. Your millage will vary depending on how often you get a 0, so you'll probably need to figure out what kind of ratio of 1s to 0s you need for your system to work reliably without losing short periods where the circuit is actually open.