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

Re: Central Count - Deck numbers - 1-17-16

Steve: How about giving me a call today and let me know what you used to shim the units. It does appear that the folds may be a problem. We are also noticing that many of the ballots have been filled in with a ball point pen on a soft surface creating a rather obvious bubble on the ballot and feel that this may also be a problem - which shimming may help to cure.
Thanks: Don 502-314-6936
----- Original Message -----
Sent: Monday, October 29, 2001 11:10 AM
Subject: Re: Central Count - Deck numbers - 1-17-16

Don, it sounds like you are getting the same rejection situation we were getting in CA. (not sure of course, but we had to shim the readers to make the opening slightly wider so that folds wouldn't screw up the timing as they wen't thru the units. 
----- Original Message -----
Sent: Saturday, October 28, 2000 9:29 AM
Subject: Re: Central Count - Deck numbers - 1-17-16

    Another question on central count: Any log action that occurs in one election such as a test version of the election also occurs in the real election. The last test deck run in the test election was 67 - the log for the real election also showed the last test deck of 67. There were no totals in the real election even though there were results in the test. The last test deck to actually be associated with the real election was 36 (this was because the customer entered the regisstration totals in the test election and wanted the test loaded as the real election at this point rather than reenter the voter reg. again).
    When the real election was started and the log cleared (the log was then cleared in all databases) the first deck number was 37 rather than the next deck being 68 the log was showing before being cleared. Is this also what is expected - is the log file associated with the EID? Is the log file a part of the backup gbf ? It would appear it is not.
    Also experiencing about a 30% rejection of ballots - timing marks. ender marks, calibration errors. I see no obvious problems with the ballots themselves. Am going to try and clean the read heads a bit to see if that helps. Any other ideas out there??
Thanks: Don
----- Original Message -----
Sent: Friday, October 27, 2000 11:47 AM
Subject: Central Count - Deck numbers - 1-17-16

    Is this the expected action in central count. Boulder County, Co., Gems 1-17-16, Central Count using batch start cards. The system assigns a batch number once a batch start card is entered. The system will assign the next number for a batch even if the election has been reset or batches have been deleted. When gems is again started it picks up where it left off assigning batch numbers. Is there a way to set the batch sequence back to start at one when the actual election begins and testing is complete? Also when a deck is deleted it simply disappears with no record in the log that it was deleted - that deck number is no longer there and the next batch number is assigned when the deck is rerun.
Thanks: Don