...  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