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

# Re: Central Count Error Messages

- To: <bugtrack@dieboldes.com>
- Subject: Re: Central Count Error Messages
- From: "Steve Knecht" <skglobal@earthlink.net>
- Date: Fri, 3 Mar 2000 12:35:34 -0800

I am working with real ballots. These can not be sent to you. Its a catch 22. Sorry. -----Original Message----- From: Guy Lancaster <glanca@dieboldes.com> To: bugtrack@dieboldes.com <bugtrack@dieboldes.com> Date: Thursday, March 02, 2000 3:48 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

- Prev by Date: Re: Central Count Error Messages
- Next by Date: Re: Central Count Error Messages
- Index(es):
  - Chronological
  - Thread