![](templates/subSilver/images/CCSLogo.jpg) |
![CCS C Software and Maintenance Offers](templates/subSilver/images/forumAd6.jpg) |
View previous topic :: View next topic |
Author |
Message |
erpgc82
Joined: 02 May 2020 Posts: 73
|
TTL barcode reader, electric pulse |
Posted: Tue Oct 12, 2021 9:29 am |
|
|
Hello friends, I'm new to programming, but in 1 year I've acquired enough knowledge to make 2 firmwares and everything works accurately, and help from you here. I'm happy.
But I'm trying to accomplish a technical feat, a child's dream! Find out how this reader works and make it work!
:-)
I work with access control equipment, which have a barcode reader. This barcode reader only has 3 pins, GND +5V and Signal.
The barcode reader reads when the code passes through the reader in a horizontal movement. Some things influence reading as an example: The speed at which the person will pass the code through the reader's beam.
The point is, I don't know where to start. I've seen in some manufacturers they use a normal pin like RA2 example, no specific pin.
I think the reading is done by converting electrical signals into binary numbers and then converting them into a decimal number.
Someone experienced, could you guide me on how to "try" to start?
edit: I've been researching in the books that I studied CCS, something like pulse width, it would be an attempt, but I don't know if it's ideal
Thanks! _________________ Gradually you will go far with persistence, will and determination!
Last edited by erpgc82 on Tue Oct 12, 2021 10:26 am; edited 1 time in total |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19358
|
|
Posted: Tue Oct 12, 2021 10:25 am |
|
|
You may not have to start at all. Many of the scanner units already
contain their own hardware to actually read the code and just return
a serial decoded number from the code. You need to start by actually
looking at the output and see if it is actually at a fixed frequency. If it
is at something like 9600bps or 19200bps it may simply be an already
decoded stream.
If not, and the data is raw, then this gets massively more complex. You
would need to start by working out what code is involved. There are at
least a dozen different common codes, and many hundreds of special
versions.
The following site gives help in identifying the symbology being used
by the code:
[url]
https://www.barcodefaq.com/barcode-match/
[/url]
The most likely types would probably be the top two there,
The commonest way that the actual barcode patterns represent
numbers is shown here:
[url]
https://www.explainthatstuff.com/barcodescanners.html#numbers
[/url]
The key is that you look for the 'edges' between black/white and white/
black, and then for each number there is always at least one part that
is only one block long. This then gives the minimum interval, and you
can then look for whether the character has 2,2,2,1 2,1,2,2 1,4,1,1
etc., blocks, to identify, 1,2,3 etc.. Because you are in each case able to
find the shortest block in the group, this gives you the speed, and time
for the interval. Where you will go wrong, is if the speed changes by
more than perhaps 25% in the character. So it is not speed, but change
of speed that gives problems. |
|
![](templates/subSilver/images/spacer.gif) |
newguy
Joined: 24 Jun 2004 Posts: 1903
|
|
Posted: Tue Oct 12, 2021 10:28 am |
|
|
Start with an oscilloscope: probe the signal pin and see what the data looks like. You need to verify but I'd be willing to bet that the data is plain old TTL serial: 1 start bit, 8 data bits, no parity, and 1 stop bit. Baud rate: probably one of the common speeds like 2400, 4800, 9600, etc. Encoding likely to be ASCII.
Once you probe the signal line and see what the data looks like, that will dictate next steps. |
|
![](templates/subSilver/images/spacer.gif) |
erpgc82
Joined: 02 May 2020 Posts: 73
|
|
Posted: Tue Oct 12, 2021 10:29 am |
|
|
Ttelmah wrote: | You may not have to start at all. Many of the scanner units already
contain their own hardware to actually read the code and just return
a serial decoded number from the code. You need to start by actually
looking at the output and see if it is actually at a fixed frequency. If it
is at something like 9600bps or 19200bps it may simply be an already
decoded stream.
If not, and the data is raw, then this gets massively more complex. You
would need to start by working out what code is involved. There are at
least a dozen different common codes, and many hundreds of special
versions.
The following site gives help in identifying the symbology being used
by the code:
[url]
https://www.barcodefaq.com/barcode-match/
[/url]
The most likely types would probably be the top two there,
The commonest way that the actual barcode patterns represent
numbers is shown here:
[url]
https://www.explainthatstuff.com/barcodescanners.html#numbers
[/url]
The key is that you look for the 'edges' between black/white and white/
black, and then for each number there is always at least one part that
is only one block long. This then gives the minimum interval, and you
can then look for whether the character has 2,2,2,1 2,1,2,2 1,4,1,1
etc., blocks, to identify, 1,2,3 etc.. Because you are in each case able to
find the shortest block in the group, this gives you the speed, and time
for the interval. Where you will go wrong, is if the speed changes by
more than perhaps 25% in the character. So it is not speed, but change
of speed that gives problems. |
hello Ttelmah. it is not serial uart.
it really is electrical pulse.
the bar codes I know in the access control market are 2/5 or 3of9, the most used is 2/5, size 6 or 8 digits.
It may take a while, I don't care if it's difficult, but I'll try! _________________ Gradually you will go far with persistence, will and determination! |
|
![](templates/subSilver/images/spacer.gif) |
erpgc82
Joined: 02 May 2020 Posts: 73
|
|
Posted: Tue Oct 12, 2021 10:33 am |
|
|
newguy wrote: | Start with an oscilloscope: probe the signal pin and see what the data looks like. You need to verify but I'd be willing to bet that the data is plain old TTL serial: 1 start bit, 8 data bits, no parity, and 1 stop bit. Baud rate: probably one of the common speeds like 2400, 4800, 9600, etc. Encoding likely to be ASCII.
Once you probe the signal line and see what the data looks like, that will dictate next steps. |
Thanks newguy, i'm going to test it on the oscilloscope tonight. I'll also connect to a regular serial set up on these 3 slow, old speeds. But most likely I only receive electrical pulses _________________ Gradually you will go far with persistence, will and determination! |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19358
|
|
Posted: Tue Oct 12, 2021 10:50 am |
|
|
Newguy is like me. All the readers I have seen, already decode the
code and just output 5v serial (or 3.3v). You need to look at the data,
but I'd expect it to be a burst of serial. |
|
![](templates/subSilver/images/spacer.gif) |
temtronic
Joined: 01 Jul 2010 Posts: 9168 Location: Greensville,Ontario
|
|
Posted: Tue Oct 12, 2021 1:14 pm |
|
|
You should post the mfr/make/model of the bar code reader. You may be able to find a manual online for it.
Some 'access control equipment' use RS-485 as the hardware interface,so it 'could' be simple 'RS-232, 9600' style serial communications.
If it's 'propriatory' equipment, they could have their own 'special' communications protocol. Makes it harder to decode but not impossible. |
|
![](templates/subSilver/images/spacer.gif) |
erpgc82
Joined: 02 May 2020 Posts: 73
|
|
Posted: Tue Oct 12, 2021 2:48 pm |
|
|
Hello gentlemen, I called the oscilloscope and a network module that I can monitor via software.
I tested several codes, with 6 digits.
In the software, serial monitor, I get only 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00, always 20 hex and always in an average time between 60 68 72 92 milliseconds, depending on the way it I pass the code into the slot of the bar reader.
The only difference is that when I step slower or faster, the time in milliseconds to reach 00 changes, but always the beginning and the end are longer. But it's always 20 hex, which arrives on the serial monitor. Note, it's not UART, it's electrical pulses.
In the oscilloscope, the waves are square, and at the beginning and at the end they remain at a low level for a longer time.
I'm thinking about creating a logic, which may not be good, but it's a start: Monitor a pin for 100ms, and for 50 times, ie every 2ms I see if the pin is at High or Low level.
Once he's at a low level, it's obvious. If it's low level I store '0' in an array of 50, if it's high level I store '1' in another address of this array. That way I'll have 50 binary numbers to work with, and convert to decimal numbers. :-D _________________ Gradually you will go far with persistence, will and determination! |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19358
|
|
Posted: Wed Oct 13, 2021 2:05 am |
|
|
First thing.
Putting a serial monitor on the data, without first working out what the baud
rate is, is totally pointless/stupid. Tells you absolutely nothing.
You need to find what the minimum pulse width is, which will be the bit
time. Reciprocate this, gives the baud rate. Also if the signal idles low, then
you need to be thinking of inverted serial. With a baud rate and polarity,
you may well have something.
Currently this is not telling you anything at all.
Then you talk about using a 6 digit code. Many readers will not handle a
code this short. Is this the 'real' code you need to read?. Have you looked
at the real code, on the web pages I gave, and worked out what encoding
is used?. |
|
![](templates/subSilver/images/spacer.gif) |
Humberto
Joined: 08 Sep 2003 Posts: 1215 Location: Buenos Aires, La Reina del Plata
|
|
Posted: Wed Oct 13, 2021 8:46 am |
|
|
I must admit that it is an atypical query. As Mr Ttelmah, Mr newguy
and Mr temtronic have clearly expressed, a standard barcode reader
obeys one of the established standards and the output pulses should
also have a universal communication protocol, USB, RS-232, RS-485
(IBM 46xx protocols), Keyboard Wedge or similar.
If what you have are plain pulses of 'ones' and 'zeros', in order to
decode and interpret them, you must know what type of barcode you are
currently trying to decode (EAN, Code 39, UPC, Code 128, etc) and
based on its decoding algorithm, with the help of an oscilloscope
and your brain in action, you will be able to interpret and decode
it in ASCII output format.
I guess that it must be a good challenge as learning and training.
regards, _________________ Humber |
|
![](templates/subSilver/images/spacer.gif) |
temtronic
Joined: 01 Jul 2010 Posts: 9168 Location: Greensville,Ontario
|
|
Posted: Wed Oct 13, 2021 10:55 am |
|
|
Yes, this WILL be a HUGE 'challenge' as there are a lot of factors to consider.
Bit widths are fairly easy with a scope, providing you have a KNOWN barcode sample. The other challenges are what format or protocol is the data ?
I surely would not assume something like RS232,8bits,no parity. This unknown reader may be custom made for a specific device, and have a unique data stream.
This is really 'reverse engineering', simple in concept, complicated to do ! |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19358
|
|
Posted: Wed Oct 13, 2021 11:50 am |
|
|
Absolutely.
As others have said, a part number from the device would be an enormous
help. This straight away will allow a lot to be found out about it.
The actual data format is why I suggested he look at the example codes
and try to work out what format is being used.
Generally, probably 80% plus of bar codes do use the numeric format I
pointed out. If so the key will be the narrowest pulse width in each group,
which is effectively the clock used. However the span of times involved does
not actually seem to be enough for the output to be directly from the sensor,
suggesting the reader is doing some interpretation/buffering. If so, identifying
the device becomes really essential. |
|
![](templates/subSilver/images/spacer.gif) |
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|