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

# RE: Central Count

- To: <support@gesn.com>
- Subject: RE: Central Count
- From: "Ian S. Piper" <ian@gesn.com>
- Date: Sun, 12 Nov 2000 14:50:18 -0600
- Importance: Normal
- In-reply-to: <PPECJKNKLDJLKJPKPPIOGEINCIAA.ken@gesn.com>

When the reader doesn't calibrate on the leading edge of the ballot, the reader sends zeros to the data stream as it is supposed to. You'd think Global could handle a simple thing like that with its central count firmware as it has done with its precinct count firmware (PC 1.94p and greater). It sounds like we should be sacrificing to the gods to save us from our software. Ian -----Original Message----- From: owner-support@gesn.com [mailto:owner-support@gesn.com]On Behalf Of Ken Clark Sent: November 06, 2000 6:45 PM To: support@gesn.com Subject: RE: Central Count If the message is "BLANK CARD FEED" as opposed to "REJECT_BLANKCARD", then yep I've seen it before. Reader not calibrating. Out of our (ie, Global software development) control. As to why it does that, you'd need to ask Luc[r]id Technology. At $700 a pop, you would think they could fix this. Either that or the ballots are not properly consecrated. You might send a sample to our priest so he can tell you how many thousands of an inch out of spec they are. If you swap machines for a few years, you might settle into some golden units that don't exhibit the behavior as often. I believe that is how Pima mitigated the problem. Ken From: owner-support@gesn.com [mailto:owner-support@gesn.com]On Behalf Of Steve Knecht Sent: Monday, November 06, 2000 6:14 AM Is anyone else running central count getting frequest "blank ballot"s when in fact the ballot is voted in each race??

- Follow-Ups:
  - Re: Central Count
    - From: "earthlink" <ken@gesn.com>

- References:
  - RE: Central Count
    - From: "Ken Clark" <ken@gesn.com>

- Prev by Date: RE: Central Count
- Next by Date: RE: Central Count Lucid Readers
- Index(es):
  - Chronological
  - Thread