On 10/20/2010 10:57 PM, Paul Boniol wrote:
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
Never mind. Without diving down the rabbit hole of USB specs, a little
reading around indicates you may be seeing raw USB data. Apparently, you
can specify how much data goes either way and 0xC0 means "End
Collection" in USB land. Not that I'm saying that it's necessarily
definitely raw USB, I just don't want to lead you astray from my
previous post.
--
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
