1

I am designing a pen-type barcode scanner (1D) which is operated by user, which means that the speed at which the scanner moves is random. Even worse is that it gets stuck sometimes, so the signal gets stretched or even goes back sometimes.

Well, all is not so bad as it sounds since I ran some tests and it seems that this distortion always happens at the 4th pulse. As it can be seen from picture, this pulse has a very long fall time. So here is the question:

What signal processing techniques can you recommend to make this right? I mean just to mark this pulse as a 1 without making the micro controller crazy? (The output of the photodiode of the scanner is fed to the ADC of a MSP430)enter image description here

Marcus Müller
  • 88,280
  • 5
  • 131
  • 237
user135819
  • 25
  • 5
  • 3
    What are we looking at, what are the axis, what created it? – PlasmaHH Jan 17 '17 at 13:13
  • This might also be a good question to move to DSP.stackexchange.com – Marcus Müller Jan 17 '17 at 13:13
  • It is the output of the photodiode, connected to the ADC of the MSP430, and read there – user135819 Jan 17 '17 at 13:14
  • @Sina: so x axis is lux and y axis is square meters? – PlasmaHH Jan 17 '17 at 13:15
  • @PlasmaHH Horizontal axis is the sample numbers, and vertical axis is the voltage of the diode – user135819 Jan 17 '17 at 13:16
  • @Sina Don't! Post it here **or** there! – Marcus Müller Jan 17 '17 at 13:18
  • "this distortion always happens at the 4th pulse" - That doesn't sound like user "jitter". Are you sure it's not some kind of hard- or software problem? – JimmyB Jan 17 '17 at 13:34
  • Also, if the user manages to "pause" half way through the code, just reject the input and have him try again. – JimmyB Jan 17 '17 at 13:37
  • Just a random thought: It will decrease the size of the scanner, but now it will require physical contact? Or it will "fly" above the barcode? – Nazar Jan 17 '17 at 13:40
  • @JimmyB smart observation, it is actually a hardware problem, but it happens between 3 to 5th pulses (because of a manufacturing property of the case) but I ran so many test in different circumstances and it seems sure to say that pulse#4 will almost always have problems (if some one suggsts a technique that works always and does not need to assume the position of the glitch then that would be really awesome) – user135819 Jan 17 '17 at 13:42
  • @Naz that is unfortunately not possible because of the design of the case – user135819 Jan 17 '17 at 13:46
  • How about using more than one sensor? This may help determining the sliding velocity. – Nazar Jan 17 '17 at 13:55
  • @Naz the sliding velocity is not a problem, the problem is the thing getting stuck which distorts the signal, and if I put two sensors, they would both get stuck – user135819 Jan 17 '17 at 14:19
  • When the error occurs, can you still reconstruct the width of the bar from the disturbed signal? Or is the length of the interference independent of the bar at the position in question? It may be impossible to reconstruct the code at all. – JimmyB Jan 18 '17 at 12:33

1 Answers1

4

You'll have to make some assumptions. A typical assumption is that the dragging speed of the user doesn't change very abruptly in the middle of a bar code.

Since barcodes contain regions of fixed, known width, it's easy to calculate the dragging speed based on that. Your algorithm just waits for the first strong "bright-dark-bright" transitions, and bases its timing on that.

For example, consider the ubiquitous EAN-13 barcodes (really, read the excellent wikipedia article from which this picture was taken):

They begin and end with two constant-width stripes. So you watch out for "bright-dark-bright" first, measure the duration of this "dark", then you expect the "bright" and the next "dark" to be as long as the first dark, and if you find that, ie. a equidistant "dark-bright-dark", you've

  1. found the beginning of an EAN barcode, and
  2. found out the "timing" of a thin stripe at the same time.

Based on the length of that "dark", you can then adjust your signal interpretation. Even slow microcontrollers will be able to do that; these barcodes were designed for 1970's electronics, after all, and they became popular when they were trivial to decode using 1980's electronics...

A note on the usage of an ADC: yes, if you have a microcontroller that has an ADC, feel free to use it. You don't have to – classically, barcode readers are implement using analog high-pass filters that only detect the edges between bright and dark (and then emit a 1 whenever there's such an edge) – you'd have to adjust your algorithms, but by reducing your analog input to a binary input, you potentially save a lot of CPU power.

Marcus Müller
  • 88,280
  • 5
  • 131
  • 237
  • Very nive review and great resources t refresh the mind on the concept of barcode, we do the same, I mean, assuming a speed for the movement and coding based on that, but that pause in the middle does happen because of a problem of the case of the device and the signal gets stretched. – user135819 Jan 17 '17 at 13:44
  • P.S. I will keep you note on outsourcing the ADC in mind, power is a big concern and if this helps, it would be very important for the final device – user135819 Jan 17 '17 at 13:45