[Date Prev][Date Next] [Chronological] [Thread] [Top]

FW: Dropping ballots in 1.94w



 
-----Original Message-----
From: Ian S. Piper [mailto:ian@dieboldes.com]
Sent: Tuesday, August 13, 2002 5:33 PM
To: Steve Moreland (E-mail)
Subject: 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:
  1. 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.
  2. 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