|
Ian to the feeder
rescue!!!
Speed variations between the feeder
and the AccuVote should not be a concern. This was a problem before
the implementation of the motor speed regulator board, but all units in the
field have that device installed.
Try this little experiment:
Unplug the AccuVote from AC Power and let it run on battery power, BUT leave the
AccuFeed plugged into AC power. The feeder will still be
operating at its standard speed, but the AccuVote will be going slower due to
the lower battery voltage (12V instead of 15V). The reader will now be
getting more scan lines on each timing mark. Your reject rate will
drop. Before the 2.00g and 1.94x firmware modifications, this experiment
brought rejects rates from 20% to 2% on limited testing.
Another experiment you can try (to satisfy your curiosity if nothing
else) is to take the feeder off of the AccuVote, but leave the AccuVote in
feeder mode. Keep the AccuVote plugged into AC Power so it is
operating at its standard speed. Now deliver the ballots one at a time to
the AccuVote reader. The AccuVote will still process the ballots
through thinking it has a feeder attached. If you get the same
percentage of read errors, then the feeder was not your
problem.
Throughput
Optimization
The slipping-then-grabbing might be
catching the AccuVote off guard. The AccuVote tries to optimize the
feeding of ballots by getting the next ballot moving in the feeder before the
AccuVote is ready to accept it. The AccuVote analyzes the time the
previous ballot got to the reader mouth when the AccuVote issued the last "feed"
command to the feeder. If it got there later than expected, then the
AccuVote shortens the delay between ballots to speed things up. If it gets
there sooner than expected, then the AccuVote lengthens the delay between
ballots to give itself more time to process the ballot it has just
scanned. When a ballot slips at the pickup roller, then grabs, that makes
the AccuVote think it has a slow feeder, so the AccuVote shortens the delay
between ballots to speed things up. But if the next ballot grabs right
away, it gets to the reader mouth well before the AccuVote is expecting
it. The AccuVote sometimes chokes on this ballot. Even though the
AccuVote senses the ballot is there, and immediately shuts the feeder down, the
ballot may get shoved into the reader by a timing mark length past the idler
side read head. This causes the ballot to not be processed.
----- Original Message -----
Sent: Thursday, March 02, 2000 5:50
PM
Subject: Re: Central Count Error
Messages
... Their feedback is that the ballots in prior revisions
would have these errors every 5 ballots or so. Now we are up to every
20 to 30 or so, depending on... what I don't know. I guess my question
is: Is this related to strictly a software issue, or is there some
tolerance level of mark on the ballot we're coming up against? Is this
in the physical world of the ballot or in the software or
both?? I was hoping that someone else
would address this but here goes.
The ballot scanning error rate is affected by many factors
including:
- the firmware's timing mark filtering algorithms,
- the firmware's
scan data processing algorithms,
- the scanner's processing of the sensor
inputs (remember that the Lucid visible light readers have their own
processors),
- the optical and electrical characteristics of the sensors,
- the operating voltages and electrical noise,
- the relative and
absolute speeds of the scanner and feeder motors,
- the ballot paper
stock,
- the cut of the ballots,
- the printing ink,
- the
tolerances of the printing of the ballot marks,
- the complexity of the
ballots (number of voting positions, complexity of voting rules, etc. which
affects timing),
- and probably a few other factors that don't come to
mind right now.
The Accu-Vote's firmware is the easiest thing to change and we do
the best that we can with the information that it receives from the scanner
boards. We probably could do better in particular cases but it's a
difficult problem with many tradeoffs for every parameter that we have to work
with. It is likely that most of your errors are a problem in
interpreting the data that the Accu-Vote gets when the ballots coming from the
feeder are moving faster than the normal speed of the Accu-Vote. The ballot
experiences a sudden deceleration and the resulting scan data is difficult to
interpret. It could also be that the feeders are slipping to a variable
degree and when they don't slip, they deliver the ballot before the Accu-Vote
is ready to scan it. It could also be that some of your ballots take
longer to process than others and again the next ballot could arrive before
the AV is ready. There's many possibilities.
Thus if you'd like us to comment on your particular situation, send
us a sample test deck and database to work with because the entire process is
quite sensative to all the ballot parameters. We'll then work from there
and try to identify the sources of the scanning errors. Otherwise be
assured that the AV runs many cross checks on the data and only accepts a
ballot when the scan data can be interpreted correctly.
Guy
|