Searching \ for '[EE] wierd idea: power LED blinks status barcode' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/displays.htm?key=led
Search entire site for: 'wierd idea: power LED blinks status barcode'.

Exact match. Not showing close matches.
PICList Thread
'[EE] wierd idea: power LED blinks status barcode'
2008\01\24@201414 by James Newton

face picon face
That is a REALLY interesting idea...

Bob has talked in the past about having an "unused" pin that sends out
status info all the time in some special format...

If you send out status data in a serial stream fast enough and continuously,
it should look more or less consistent when used to light the power on LED
on the widget you are making.

For no extra cost, you get a visible status data stream.

Of course, you can't read it with the naked eye... Other than to note that
the light goes out or comes on brighter when the uC stops running.

Then the question is what can you use to read it? What if the light pattern
was the same as what a barcode reader would see if it was scanned over an
area? So assuming your customer has a barcode reader connected to his or her
keyboard (as is the case at a lot of POS terminals) then you just tell them
to go to a web page that you have set up, and then point the barcode wand
right over the power LED on your widget. Some JavaScript on the page parses
the data stream, breaks it off in chunks and sends them to you via AJAX.

Or perhaps IRdA is the better protocol?

What do PDA's talk in when you "beam" contacts between units?

At worst, you send them a "visible light to RS232 adapter" which everyone
has laying around right?

On Wed, Jan 23, 2008 at 12:05:24PM -0700, Dwayne Reid wrote:
The other neat trick I'm doing is that one of the LEDs is actually
spitting out a serial bit stream while it is lit.  

<snip>

2008\01\24@210450 by Marcel Duchamp

picon face
It *is* a cool idea.  Someone on the list a few years back mentioned
that Hewlett-Packard used this for diagnostic data via a front panel LED
display.  Barfed out code version or some such.  I seem to remember that
it was done in the 70s or 80s.

I considered using it once to extract the data from a datalogger that
could not afford to have connectors that were not perfectly water proof.

A related idea to this was distribution of software via your friendly
television set.  I think the Jeopardy home game that allowed you to play
along with the show did this.  They modulated pixels near the bottom of
the screen and the home users game equipment picked it up.

James Newton wrote:
> That is a REALLY interesting idea...
>

2008\01\24@213343 by William Couture

face picon face
On Thu, Jan 24, 2008 at 8:15 PM, James Newton <spam_OUTjamesnewtonTakeThisOuTspammassmind.org> wrote:

{Quote hidden}

A few years ago, I had the status LED blink an error message in Morse
Code.  My manager said I had *WAY* too much time on my hands...

Bill

--
Psst...  Hey, you... Buddy...  Want a kitten?  straycatblues.petfinder.org

2008\01\24@213446 by Spehro Pefhany

picon face
At 09:03 PM 1/24/2008, you wrote:
>It *is* a cool idea.  Someone on the list a few years back mentioned
>that Hewlett-Packard used this for diagnostic data via a front panel LED
>display.  Barfed out code version or some such.  I seem to remember that
>it was done in the 70s or 80s.
>
>I considered using it once to extract the data from a datalogger that
>could not afford to have connectors that were not perfectly water proof.
>
>A related idea to this was distribution of software via your friendly
>television set.  I think the Jeopardy home game that allowed you to play
>along with the show did this.  They modulated pixels near the bottom of
>the screen and the home users game equipment picked it up.

If you wanted to use standard UARTs, suppose you sent one byte at 9600
baud every 5msec (periodic ISR or whatever) continuously. You send a byte,
then the complement, which keeps the average brightness constant visually
since the average over 10msec (100Hz) will be constant.

>Best regards,

Spehro Pefhany --"it's the network..."            "The Journey is the reward"
.....speffKILLspamspam@spam@interlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com



2008\01\24@221108 by Dwayne Reid

flavicon
face
At 06:15 PM 1/24/2008, James Newton wrote:

>If you send out status data in a serial stream fast enough and continuously,
>it should look more or less consistent when used to light the power on LED
>on the widget you are making.

I would have to give Robert Rolf credit for the original inspiration.

I'm not sure if he would even remember it, but we built a project
many (15?) years ago that was essentially a large "guess the magic
number" contest for a radio station promotion.  It made use of large
LED-based displays that lived over top of a clear plexi-glass case
containing a prize.  Each lucky contestant would enter their guess on
a simple keypad.  A correct guess caused the case to open, allowing
the prize to be retrieved.

Robert suggested that I have the LED displays encode the correct
answer as a serial bitstream so that he could win the prize should he
become one of the lucky contestants . . .

I didn't take him up on his request at that time - it just wouldn't
have been right <grin>.


I've received a lot of email on this issue - I can't share code but I
can certainly tell you what I did.

1) Idle condition (that is: "Disconnected Idle" condition) is that a
particular LED is transmitting (0x00 0x00 pause) whenever it is
lit.  A logical zero = LED on - that means that the LED is running at
about 80% brightness.

2) I'm using super-bright T1 red LED as the indicator / transmit LED.

3) The receiver is a Industrial Fiber Optics IF-D92 photo transistor
with a short length of 1mm jacketed plastic fiber.  The free end of
the fiber has a Hellerman sleeve glued such that the sleeve will fit
over the T1 LED and hold the end of the fiber in contact with the LED.

For those who aren't familiar with Hellerman sleeves, they are an
alternative to heat shrink tubing (probably pre-date heat shrink
tubing).  They are made from a super-elastic neoprene rubber and can
be stretched to 5 or 10 times their collapsed diameter using a
special tool.  In this case, no stretching required.  The sleeves are
about 1mm or so inside diameter, about 20mm (3/4") long.  I simply
slide the sleeve onto the free end of the jacketed fiber, then glue
it so that it doesn't slide around.  The sleeve grips the body of the
T1 LED tightly when pushed on.


How it works:

The LED normally blinks.  Each blink transmits the "disconnected
idle" token (0x00).

When the fiber is pushed onto the LED, the display system detects the
token (0x00, 0x00) and prompts the user to press and hold both buttons.

After a 2 second or so delay, a different token is transmitted.  That
causes the display to prompt the user to release button #1.

Shortly after button 1 has been released (but button 2 is still
pressed), the LED transmits the next token.  The display prompts the
user to release the 2nd button.

If the buttons are released at the correct times, the controller is
pretty sure that the display is connected and working.  It transmits
its "connected idle" token to the display, which causes the display
to present the highest menu level.

From this point on, you can do whatever you like using the
interactive display and 2 buttons.

If no button is pressed after an appropriate idle time, the
controller reverts back to "dumb blinky LED" mode and transmits the
"disconnected idle" token during blinks again.


Notes:

1) the hand-held display unit contains all the text strings needed
for the product.  The token sent by the controller simply selects the
appropriate string(s) for display.

2) All data needed for specific fields on the display are transmitted
along with the appropriate token for that menu level.

3) I've been using standard 8n1 serial up to this point (bit-banged
on a 12F675 or 12CE671).  I'm considering changing my next project
using this system to encode the data with Manchester or MFM
encoding.  The 12CE671-based systems used a resonator but I've been
lucky enough that the internal RC clock in the 12F675 has been
adequately accurate for reliable communications.

FWIW - the early units used a modestly self-correcting serial receive
routine that I've posted previously.  This receive routine is based
upon John Payson's 40 bit long serial receive buffer, where an entire
character is sampled at 3 times the baud rate and stored in a 40 bit
long shift register.  The character is decoded when the start bit
reaches the end of the register - one can then examine the bit
transitions and make a "best guess" as to the location of each
bit.  Sounds complicated but its not too bad.  Isochronous code at
its best <grin>.

The MFM modulation I mention above is a primitive 25% / 75% duty
cycle modulation that I've been using for at least 20 years.  Its
charm is that its extremely easy to generate in hardware and very
easy to decode.  That, plus the ability to maintain accurate
communications over the range of about 60% through 170% baud rate
variation.  The downside is a 2 times drop in effective data rate
compared to Manchester encoding (it requires 4 bit slices compared to
Manchester's 2 bit slices).


Other notes:

I'll sometimes set the card up so that it always powers up in smart
(interactive) mode for the first 2 or 3 power-up cycles.  That makes
production testing easier.  It stores how many times its been powered
up in eeprom - then stops counting after the appropriate number has
been reached.


I've been asked if this has been patented.  Quite frankly, I
considered it to be an obvious technique and thus in the public
domain.  I certainly hope that it remains in the public domain.

dwayne

--
Dwayne Reid   <dwaynerspamKILLspamplanet.eon.net>
Trinity Electronics Systems Ltd    Edmonton, AB, CANADA
(780) 489-3199 voice          (780) 487-6397 fax
http://www.trinity-electronics.com
Custom Electronics Design and Manufacturing

2008\01\25@000729 by Bob Axtell

face picon face
Spehro Pefhany wrote:
{Quote hidden}

Ooo, I like this one. If the protocol is 8/N/1, 10 bits, then the
average brightness would indeed be
constant....

--Bob

2008\01\25@042326 by Alan B. Pearce

face picon face
>For those who aren't familiar with Hellerman sleeves, they are
>an alternative to heat shrink tubing (probably pre-date heat
>shrink tubing).

Hellermann Sleeves - man that takes me back to my apprenticeship days in the
late 60s. The company I worked for used them extensively on the looms in all
the items they produced. IIRC heat shrink was available, but I suspect
relatively expensive. We certainly used heat shrink on other products where
necessary.

Nowadays of course, such loom tying would be done with cable ties.

2008\01\25@045449 by Richard Prosser

picon face
Allan,
You'd also no doubt remember the hand lacing.

RP

On 25/01/2008, Alan B. Pearce <.....A.B.PearceKILLspamspam.....rl.ac.uk> wrote:
{Quote hidden}

> -

2008\01\25@055535 by Alan B. Pearce

face picon face
>Allan,
>You'd also no doubt remember the hand lacing.

Yes, but we did not do much of that. For our purposes it was quicker and
easier to use the Hellermann Sleeves.

2008\01\25@121118 by Charles Craft

picon face
We used them for wire numbers - short yellow pieces with the number
stamped in black on them. 3 digit number - 3 pieces to slide over
the wire and don't get the digits backwards. :-)

-----Original Message-----
{Quote hidden}

>-

2008\01\25@131854 by rlistas

picon face
Hi James,


Welcome to http://www.sirpic.com :>)

I´m using it for diagnose my circuits for about 3 years now.
Works perfect.

Just pay attetion that some palms didn´t accept raw IRDA,
just IRCOMM. Another detail is that the clock must be
very precise. I have some trouble with PICs 12F675 and 16F676
with internal oscillators, even with 1200bauds.

I use simple IR leds (remote control ones) and only software.

Zire Z22, the cheapest now, is the best I have used for this.


Best regards,

Rubens




At 23:15 24/1/2008, you wrote:
{Quote hidden}

2008\01\25@140504 by James Newton

face picon face
www.sirpic.com has code to allow a Palm to receive (and send given
the required hardware) signals with a PIC via IR or hardwire interface.

Most excellent! It's good to know other people have had the same idea. For
anyone who looks at this, the actual PIC code is in
http://www.sirpic.com/downloads/SirPicProgrammersGuide_v1_1.pdf and Rubens
is selling (at a very reasonable price) a Palm app that displays the
incoming data.

I do have a few questions:

I've never worked with an IR transmitter module:

Do they show a visible light of any sort? This would allow it to serve dual
purpose as the status or power on light.

Do they cost significantly more than a standard LED? I assume so, but maybe
I'm wrong.

Can a standard LED have any hope of actually communicating with a Palm?

If I designed a product with your PIC code built in and an IR transmitter,
what royalty issues do I face and can I license the Palm code to my
customers?

And finally, I'm sort of waiting for someone with a lot of barcode
experience *cough, Dave* to comment on the original idea of using the LED to
put out pulses of light that a barcode wand might interpret in the same way
it picks up changes in the reflected light level from an actual bar code. IF
that would work, it seems to me that it would be VERY handy in some
environments.

--
James.

{Original Message removed}

2008\01\25@141411 by rlistas

picon face
James!

I have nothing with SirPIC !!!!!!
I just indicate it to the list !!!!

Rubens


At 17:05 25/1/2008, you wrote:
{Quote hidden}

>{Original Message removed}

2008\01\26@095115 by David VanHorn

picon face
>         I searched everywhere I could thing of and did not find John's code
> or yours :-( Could you post some reference to it or repost the code ? It is
> a very interesting technique and I would love to see how you approached the
> "clock recovery".. I use bit-bang a lot for serial comms but never thought
> about using a bit buffer to make a better decision about the timing...

I'd be interested too.   I've used a single pin with my "pong" routine
(Ping just blips a bit N times) to output multiple bytes in
wide-narrow form, such that for any combination of timings, the byte
is the same length.  Helps enormously when you're capturing say 50
bytes of data on the scope.

2008\01\26@104853 by Peter Todd

picon face
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, Jan 24, 2008 at 05:15:10PM -0800, James Newton wrote:
{Quote hidden}

I think I've got it...

A typical scenario in my projects is to have a bunch of leds controlled
by a master OE pin of some sort. I always connect those OE pins to a PWM
pin on the PIC, although, they may or may not actually implement
dimming, but the connection is there.

Now most of you guys have been focusing on various modulation strategies
that average out to a given brightness level. Given that this is
debugging info, we probably don't really need to actually pass that much
data around however, which means are bit rates can be low. That said, an
led has a heck of a lot of bandwith...

So instead make your data transmission extremely *short*, so short that
the brightness decrease isn't noticable. The average bit-rate will be
still low, but we've already decided that's ok.

I built a simple 1-pin unidirectional data transfer concept awhile back
where single byte data packets were prefixed with a 32-bit random
number. The reciever would then sample bits at the correct clock rate
constantly, and whenever that magic number appeared, sample the next
8-bits and call it data. Worked really nicely, and could even be fairly
error free with some simple tactics like replicating each data bit three
times/checksums/something.

My initial test assumed fixed baud rates, although a more intelligent
decoder could do stuff like determine the timing between the first bit,
(low->high->low) and sample based on that.

In all the whole device could be implemented in a little dongle with a
high speed visible wavelength photo-diode sensor, a pic to decode, and a
rs232 output at the other end.

- --
http://petertodd.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHm1VC3bMhDbI9xWQRAiMIAKCsIdajea5Y4u7nwhSP0aV3LLTtUgCePobt
1O7DK6YDI6fgJiNIg9/IMeM=
=jNS8
-----END PGP SIGNATURE-----

2008\01\28@092449 by Bob Axtell

face picon face
David VanHorn wrote:
>>         I searched everywhere I could thing of and did not find John's code
>> or yours :-( Could you post some reference to it or repost the code ? It is
>> a very interesting technique and I would love to see how you approached the
>> "clock recovery".. I use bit-bang a lot for serial comms but never thought
>> about using a bit buffer to make a better decision about the timing...
>>    
>
> I'd be interested too.   I've used a single pin with my "pong" routine
> (Ping just blips a bit N times) to output multiple bytes in
> wide-narrow form, such that for any combination of timings, the byte
> is the same length.  Helps enormously when you're capturing say 50
> bytes of data on the scope.
>  
Are you guys talking to me? I have the PIC code as well as the DOS PC
receiver app for Manchester-
like coding, which is not sensitive to timing errors. While I usually
send my code at 4mS per bit, it
will work at 50mS/bit or at 1mS/bit just as well.

Let me know.

--Bob Axtell

2008\01\28@093218 by Peter Todd

picon face
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, Jan 28, 2008 at 07:24:32AM -0700, Bob Axtell wrote:
{Quote hidden}

Send it over! Much appreciated.

(so long as I can combine it in GPLed code)

- --
http://petertodd.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHneZ13bMhDbI9xWQRAimvAJ93NduL2a/s96CNEIhro+IuAqwLjACZAc7Z
yIigkMag3SBr4owNPNONUjA=
=c0RP
-----END PGP SIGNATURE-----

2008\01\28@095112 by John Coppens

flavicon
face
On Thu, 24 Jan 2008 22:07:24 -0700
Bob Axtell <@spam@engineerKILLspamspamcotse.net> wrote:

> Ooo, I like this one. If the protocol is 8/N/1, 10 bits, then the
> average brightness would indeed be
> constant....

Why not use NRZ(i) code? That code was designed to be 'constant'
intensity, be it for magnetic media. It has the added advantage that it
contains a clock, and polarity is unimportant. Easy to decode and encode
too.

John

2008\01\28@101145 by Alan B. Pearce

face picon face
>> Are you guys talking to me? I have the PIC code as well as the DOS PC
>> receiver app for Manchester-
>> like coding, which is not sensitive to timing errors. While I usually
>> send my code at 4mS per bit, it
>> will work at 50mS/bit or at 1mS/bit just as well.
>>
>> Let me know.
>
>Send it over! Much appreciated.
>
>(so long as I can combine it in GPLed code)

I wouldn't mind a copy also please, if you are not going to post it on a web
page.

TIA

Alan

2008\01\28@101629 by Bob Axtell

face picon face
Peter Todd wrote:
{Quote hidden}

You can do whatever you want with it. Give me a day to get it from my
consultant archive; I am
at my client's computer. don't have much stuff here.

--Bob A

{Quote hidden}

2008\01\28@110331 by John Coppens

flavicon
face
On Mon, 28 Jan 2008 12:50:35 -0200
John Coppens <KILLspamjohnKILLspamspamjcoppens.com> wrote:

> Why not use NRZ(i) code? That code was designed to be 'constant'
> intensity, be it for magnetic media. It has the added advantage that it
> contains a clock, and polarity is unimportant. Easy to decode and encode
> too.

I really meant NRZI + manchester coding, of course. It's the manchester
coding that evens out the DC level. Though NRZI alone should probably be
better than just serial data.

John

2008\01\28@155655 by James Newton

face picon face
I'm still really interested to hear from anyone who does barcode readers:
Can an LED be used to generate a pattern of light and dark that a barcode
wand would see as if it were a barcode?


--
James.

2008\01\28@162808 by David VanHorn

picon face
On Jan 28, 2008 3:57 PM, James Newton <RemoveMEjamesnewtonTakeThisOuTspammassmind.org> wrote:
> I'm still really interested to hear from anyone who does barcode readers:
> Can an LED be used to generate a pattern of light and dark that a barcode
> wand would see as if it were a barcode?

That would be me, and generally speaking, no.
They work on reflectance. You'd have to set things up optically so
that the transmitted energy gets dumped somewhere, not returning to
the reader, and the led instead gets there.  For a contact based wand,
that's maybe possible.
With a laser scanner, the read optics are scanned along with the beam,
so I'd bet not.  Laser wands also usually have filters for wavelength,
but you might be able to source an LED that gets thru them.

2008\01\28@163125 by Jason Harper

picon face
On Jan 28, 2008, at 2:57 PM, James Newton wrote:
> I'm still really interested to hear from anyone who does barcode  
> readers:
> Can an LED be used to generate a pattern of light and dark that a  
> barcode
> wand would see as if it were a barcode?

Previous copy of this reply didn't seem to have gotten through:
==========

There's no way it could be done with 100% compatibility.

It would likely work with wands that have to be manually swiped  
across the barcode, IF the LED color matched the wand's sensor.  Red  
show work for many, however there are some wands that use IR - the  
idea being that they can also read barcodes that have been concealed  
by overprinting with an IR-transparent ink.  I have no idea how  
common IR wands are.

Non-contact scanners that use a linear CCD array would have no chance  
at all of reading anything from a single LED.

The scanners (typically gun-shaped) that use a laser and rotating  
mirror fall somewhere in the middle - they could work, but it's also  
possible that they're doing something like synchronizing their  
decoding with the mirror rotation.


2008\01\28@164356 by Apptech

face
flavicon
face
> I'm still really interested to hear from anyone who does
> barcode readers:
> Can an LED be used to generate a pattern of light and dark
> that a barcode
> wand would see as if it were a barcode?

No practical experience of this, but I'd hazard that it
would certainly work in some cases and certainly fail in
others.

Wands which rely on physical movement of the wand wrt the
target and laser scanners which take the action to the
stationary target would seem to present somewhat different
challenges.

A LASER scanner should be able to be tested for operation by
determining the san rate and then modulating an LED of about
the right wavelength appropriately. Better still would be a
device which you could time vary the reflectance of. Then
instead of grossly time modulating the whole display with
the pattern you could consider varying it in time sequence
geographically across the "display" and before you know it
you have a reflective LCD barcode display :-).


       Russell


2008\01\28@172629 by David VanHorn

picon face
> It would likely work with wands that have to be manually swiped
> across the barcode, IF the LED color matched the wand's sensor.

Some have filters, some don't.

>  Red show work for many, however there are some wands that use IR

True, but not popular in retail.


> Non-contact scanners that use a linear CCD array would have no chance
> at all of reading anything from a single LED.

Yup, they need something they can image.


> The scanners (typically gun-shaped) that use a laser and rotating
> mirror fall somewhere in the middle - they could work, but it's also
> possible that they're doing something like synchronizing their
> decoding with the mirror rotation.

The receive optics usually are steered by the same mirror that sweeps
the transmit beam, so you'd have no way to get in the field of view
all the time.  Also they frequently have narrow filters on the rx
optics, but you might find an LED that gets you through that.

2008\01\28@174143 by M. Adam Davis

face picon face
The only thing that hasn't been mentioned is that a lot of visible
light scanners modulate the laser or lighting element to seperate
signal and noise, such as from flourescent lights, etc.

So even if you had the simplest barcode scanner (a wand you swiped
across the barcode) if it was modultated you'd be unable to sense and
respond appropriately with a transmit only scenario.

-Adam

On 1/28/08, James Newton <spamBeGonejamesnewtonspamBeGonespammassmind.org> wrote:
> I'm still really interested to hear from anyone who does barcode readers:
> Can an LED be used to generate a pattern of light and dark that a barcode
> wand would see as if it were a barcode?
>
>
> --
> James.
>
> -

2008\01\28@175557 by David VanHorn

picon face
On Jan 28, 2008 5:41 PM, M. Adam Davis <TakeThisOuTstienmanEraseMEspamspam_OUTgmail.com> wrote:
> The only thing that hasn't been mentioned is that a lot of visible
> light scanners modulate the laser or lighting element to seperate
> signal and noise, such as from flourescent lights, etc.

I don't know that that is true.
I've actually not opened one yet that did this.
I spent a lot of time working with barcode systems.


> So even if you had the simplest barcode scanner (a wand you swiped
> across the barcode) if it was modultated you'd be unable to sense and
> respond appropriately with a transmit only scenario.

If you were able to modulate the reflectance of a target quickly
enough, you could.
Look at the codes printed on drink cans, where the bar elements are
silver and white.
The silver looks "black" to the optics because it's a specular, not
diffuse reflection.
An LCD film over a mirror, might work if it could be thin enough.

2008\01\29@040438 by Alan B. Pearce

face picon face
>I'm still really interested to hear from anyone who does barcode
>readers: Can an LED be used to generate a pattern of light and
>dark that a barcode wand would see as if it were a barcode?

I don't see a problem with doing so. When you first posted this idea I had
visions of turning off the LED in my Cuecat, and using that as the reader.

It is certainly a variation of the concept of using LED output that I want
to follow up.



2008\01\29@101720 by William Couture

face picon face
On Mon, Jan 28, 2008 at 3:57 PM, James Newton <RemoveMEjamesnewtonspamTakeThisOuTmassmind.org> wrote:

> I'm still really interested to hear from anyone who does barcode readers:
>  Can an LED be used to generate a pattern of light and dark that a barcode
>  wand would see as if it were a barcode?

Having done barcodes in a previous job, I'm going to say that only a
very low-end
barcode reader (like a CueCat -- http://en.wikipedia.org/wiki/CueCat -- or other
wand-based barcode scanner) would be able to read a "barcode" from an LED.

The information is encoded in the relative width and spacing of the bars, and
will translate into a time sequence only by knowing the location / velocity
of the scanning laser / LED.

For a high-end mirrorwheel scanner, this scanning is non-linear (the ends of
the scan are faster than the middle of the scan), but not too hard to
figure out.

For a lower-end vibrating vane, the scan is again non-linear, but somewhat
harder to figure out.

For a "bottom-end" wand scanner (for example,
instruct1.cit.cornell.edu/courses/ee476/FinalProjects/s2004/mtf23/BarcodeScanner/index.htm
ATMega based, not PIC based -- sorry!) or a CueCat, the scan is assumed
to be linear (the movement of your hand), with very simple mechanical and
processing requirements.  Thus, relative time is directly translated into bar
width / spacing.

If you really want to transfer a complicated message via status LED, it seems
you'd be better off using a simple RS232 protocol.  Make a definition that
there must be a quiet period (say 1 second) between messages (I'm going
to assume that the message is repeated, or that different messages are
going to be sent in sequence), followed by a standard RS232 encoding.
The quiet period makes sure you are synchronized to the message.
For receiving, all you need is a photodiode and a processor.

Note that this assumes that the status LED is constantly ON (at least
visually).  In projects around here, our status LED fades in to full
brightness, then goes back to dark in a 1-second cycle.  A constantly
ON LED just says that power is being applied and the bit is set, a
cycling LED says that processing is actually taking place.

Although, you could use a constantly ON LED as an error indication,
and then look for the RS232 stream with your detector.

Bill

--
Psst...  Hey, you... Buddy...  Want a kitten?  straycatblues.petfinder.org

2008\01\29@103539 by David VanHorn

picon face
> For a "bottom-end" wand scanner (for example,
> http://instruct1.cit.cornell.edu/courses/ee476/FinalProjects/s2004/mtf23/BarcodeScanner/index.htm

How low can you go?  :)  My UPC/EAN/UPC-E/EAN-8 with 2 and 5 digit
supplementals, forward and backward, was implemented in a 2343.

> ATMega based, not PIC based -- sorry!) or a CueCat, the scan is assumed
> to be linear (the movement of your hand), with very simple mechanical and
> processing requirements.  Thus, relative time is directly translated into bar
> width / spacing.

Yes, all true, I think barcode pen was the original query.
Shutting off it's LED would certainly help.

2008\01\29@110812 by Alan B. Pearce

face picon face
>For a "bottom-end" wand scanner (for example,
> instruct1.cit.cornell.edu/courses/ee476/FinalProjects/s2004/mtf23/BarcodeScanner/index.htm
>ATMega based, not PIC based -- sorry!) or a CueCat, the scan
>is assumed to be linear (the movement of your hand), with very
>simple mechanical and processing requirements.  Thus, relative
>time is directly translated into bar width / spacing.

For those who haven't looked into doing this, there is an extremely good
description of how to handle decoding a barcode from a hand held wand, in
the original Motorola 6800 Application Manual (issued late 60's, early
70's), where they 'design' a POS terminal to illustrate various applications
a micro can be put to. The section in that on barcodes was my introduction
to them, and still is deemed a useful reference manual.

2008\01\29@112344 by David VanHorn

picon face
> For those who haven't looked into doing this, there is an extremely good
> description of how to handle decoding a barcode from a hand held wand, in
> the original Motorola 6800 Application Manual (issued late 60's, early
> 70's), where they 'design' a POS terminal to illustrate various applications
> a micro can be put to. The section in that on barcodes was my introduction
> to them, and still is deemed a useful reference manual.

Is that available in PDF somewhere?

2008\01\29@120946 by Alan B. Pearce

face picon face
>> the original Motorola 6800 Application Manual
>>(issued late 60's, early 70's),
>
>Is that available in PDF somewhere?

I doubt it ever was originally in PDF form - this thing pre-dates any
personal computer ... ;)

It may have been scanned since. Mine is packed away at the moment, but could
try and look it out at the weekend.

2008\01\29@123614 by Marcel Duchamp

picon face
Alan B. Pearce wrote:
>>> the original Motorola 6800 Application Manual
>>> (issued late 60's, early 70's),
>> Is that available in PDF somewhere?
>
> I doubt it ever was originally in PDF form - this thing pre-dates any
> personal computer ... ;)
>
> It may have been scanned since. Mine is packed away at the moment, but could
> try and look it out at the weekend.
>

As a starting place, I find wikipedia often has good links...

At the bottom of this page:
http://en.wikipedia.org/wiki/Motorola_6800
is a link to "MC6800 applications manual from 1975- lots of information"
actual link:
http://www.bitsavers.org/pdf/motorola/M6800applMan_Mar75.pdf

This is a 36 meg pdf file.  Chapter five has "scanning wand for
capturing data from printed symbols" and includes the example of UPC
reading.

The entire document is an image scan so text searching does not work.

2008\01\29@130156 by David VanHorn

picon face
> This is a 36 meg pdf file.  Chapter five has "scanning wand for
> capturing data from printed symbols" and includes the example of UPC
> reading.

Thanks!

I have a lot of barcode info, but very little is available on decoding.
Mostly it's encoding, which isn't the same thing.

Decoding would get into all the cool features that make the code
practically bulletproof.

2008\01\29@131456 by Alan B. Pearce

face picon face
>is a link to "MC6800 applications manual from 1975- lots of
>information" actual link:
> http://www.bitsavers.org/pdf/motorola/M6800applMan_Mar75.pdf
>
>This is a 36 meg pdf file.  Chapter five has "scanning wand for
>capturing data from printed symbols" and includes the example of UPC
>reading.
>
>The entire document is an image scan so text searching does not work.

Yep, that looks like the beastie all right.

More... (looser matching)
- Last day of these posts
- In 2008 , 2009 only
- Today
- New search...