TTL barcode reader, electric pulse

[erpgc82]

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!

[Ttelmah]

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.

[newguy]

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.

[erpgc82]

[erpgc82]

[Ttelmah]

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.

[temtronic]

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.

[erpgc82]

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!

[Ttelmah]

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?.

[Humberto]

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

[temtronic]

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 !

[Ttelmah]

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.