[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
FW: Dropping ballots in 1.94w
Steve
Moreland:
Below
is a recently reported bug (#1393) in 1.94w AV-OS firmware that could explain
some occasional dropped ballots that have been reported when using
this revision of AV-OS firmware. In the past, dropped ballots
have usually been written off as PollWorker error. This situation can
occur when the first ballot is processed any time after an AV-OS is powered
up. I wanted to be sure that the support staff is aware of this issue
going into the upcoming election cycle. Steve Moreland: If you wish to
modify or add to this email prior to posting, please proceed and post to the
support list.
This
bug is only a concern if you have a memory card that has data that is
over 75K in size (5K back from 80K for headroom's sake.) Even with
election data of that size, this bug will only happen on VL units that
have a reader running at 27 inches per second (the top acceptable speced
speed.) I don't have info as to what percentage of units would be running
at that speed. The only way to qualify a unit is to use the size of
the data on the memory card as a reason to test and to actually put a
ballot that will not process through a unit after power up and witness that it
rejects properly, while attached to AC power. If the ballot goes straight
through the reader, then the unit will be susceptible to this bug on election
day.
Remember that this bug only affects the first ballot
scanned after power up. Any subsequent ballot scanned is
handled properly. If election ballots are the first ballot
through a unit at power up, you wouldn't notice the problem unless that
first ballot was rejected. If it scanned properly, the ballot would be in
the Ballot Box and the public counter would increment by one. No one would
notice unless they were watching the back side of the reader (which is usually
covered by the Ballot Box slot during an election.)
Possible work arounds:
- At
power up, make the first card that goes through the unit a Diagnostic Card or
a Start Card (i.e., something that will not process in election mode and also
be easily separated from the ballots in the Ballot Box.) As this would
have to be done each time the AV-OS unit power is cycled, this initial
ballot will have to be retrieved after use so it will be easily available
for the next time it's needed.
- Unplug the AC power cord while scanning the first
ballot after power up. Running on battery power reduces the reader speed
and allows the firmware to complete its initialization before the ballot is
finished scanning, thereby maintaining control of the
ballot.
Remember that any time the AV-OS unit is power OFF and
ON, this same process would need to be followed. This bug is not dependent
on the first ballot of the day, it is dependent on the first ballot after power
up.
(Bug
#1393 submitted by Steve Ricke)
Problem:
A reject ballot (Blank, wrong precinct, ender,
etc.) inserted into AVOS after
initial power up is not returned (i.e., the ballot is
dropped.) The LCD reports the ballot has
been
returned. Any additional ballots are processed correctly.
This would happen
each time the unit was powered up in both pre-election and
election modes
(i.e., every time the AV-OS unit is power cycled throughout the day, this
could happen regardless of the ballot counter status.)
Background:
The AccuVote and programmed memory cards
(City and County Absentee, Laramie
2002 primary) were returned from field
for verification of the problem. The
same cards were reported to
exhibit the same problem on several VL Accuvotes.
With some VL
Accuvotes the problem could not be duplicated. On all IR
Accuvotes the
problem could not be duplicated.
I removed ten precincts from the county absentee vote
center and created a
memory card with a "calc size" of 80K. Using this
card, all ballots were
processed
correctly with all the aforementioned readers. (My guess is the
problem is related to the number of ballot images on the card)
I
suspect the large amount of data being processed from the memory card during
the first ballot processed is causing a timing issue with the braking at the
end of the ballot.
(Resolved by Jason Wong)
An almost filled memory card caused a lengthy time for a
checksum to finish
preventing variables from being initialized. This
resulted in the first
ballot not being rejected if a reject ballot
cast. This is fixed and will be in
1.96.4