On Wed, Oct 20, 2010 at 9:42 PM, Jim Peterson <[email protected]> wrote: > I must state here that I am not an expert in these matters, but the way it > seems to work with our scanners is the scanner reads the barcode and > automatically inserts a CR, indicating the EOL for that particular data > field, and the program spits out the proper entry from the DB. I only point > to that because I can manually enter the barcode number, but the program > will not progress until I manually hit Enter, which indicates to me that the > CR HAS to be inserted to tell the program that what was entered is the end > of the input field. > > Additionally, our barcodes are a standard 14-number format, which is > programmable to different number combinations. It sounds like your pattern > is different from ours because we only encode the 14 digits, and yours will > probably have some sort of hex or ASCII code for encryption, assuming the > cards are for security/identity, and the identifying info for the > cardholder. > > I hope I've helped. If I haven't, just tell me to shut up! > > Jim Peterson > > On Wed, 2010-10-20 at 19:55 -0500, Paul Boniol wrote: > >> Paul Boniol >> > > I've got it working, though I'm seeing what I'm guessing is more low > level information mixed in the data. It seems to follow the pattern: > > /(\x00|\xC0)\x02\xN/ where N is the number of bytes of data > following, up to 5 bytes. (The Card office encodes I believe 25 > characters in the stripe that I need to read + 1 CR.) It threw me for > a minute because the low ASCII characters aren't displayed on the > screen by cat, and the C0 just started after a reboot. > > Is this format normal/documented for raw /dev files? >
I am pretty sure the CR in inserted by our scanner (and likely yours as well). This is a configuration option in the two different scanners setup programs that I have seen (bar code and mag stripe). This is for ease of use, like submitting data or going to the next line. The /(\x00|xC0)\x02\xN/ is not part of the data in the stripe and is not seen at higher levels in Windows (at least not displayed in the config program's test display). It could be something pertaining to the "serial" config of a USB device? It's been ages since I've seen a raw serial stream and I never saw much even back then. Wikipedia says Xon/Xoff is \x11 and \x13 respectively so it's not Xon/Xoff. Reading from a /dev/hidraw*, device though, you are likely getting the raw data stream from the device. This will include other data. (If you have a USB keyboard, pipe the raw output to a file, type some characters and use hexdump on the file. You will probably have far more characters than the letters you typed.) I am now wondering if the pattern I saw was a standard of some sort or if every device has it's own unique way... Devices not adhering to a standard would be most confusing but is the way a lot of hardware companies operate. Paul -- You received this message because you are subscribed to the Google Groups "NLUG" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nlug-talk?hl=en
