Cheapest way to make 3 LEDs blink a specific pattern ID

[jpauclair]

Hi,
I would like to have some inputs on the cheapest possible way to make 3 LEDs blink (independently) with a specific pattern representing an ID (at least 8 bits)
So lets say the first LED ID is 234, then its binary value is 11101010, and we would open the LED for each 1 and close it for each 0, for a fixed amount of time.
The ID is static, and does not need to be updated.

My main two options:
Option 1: Using a pic10f200, 3 outputs, and program it to control each LED state.

Option 2: Using a 555 timer with 3x CD4017, and "physically" link each "1" to matching pins of the cd4017.
for the ID: 11101010, we would link pin 0,1,2,4,6 to the led, the others would do nothing.

Option 3:
*Your answer here*

I have 2 goals:
-Identify the cheapest possible cost for this application (maybe the 555 option?)
-Identify the smallest spacing require to do it. (maybe the 10f200?)

*consider the pricing for very very large volumes, not only a couple of boards.
Thank you!

EDIT: TLDR, clarifications

1: I want to get an identification (ID) for a very small object.
2: I want to be able to get that ID from far (2-3 meters)
3: I don't wanna get into bluetooth and that sort of things... I want it to be  < 0.2$
4: I could use QR code, or any visual marker, but the area is very small, so at 2-3m, it worth nothing.
5: the information I need to get is only an ID (let's say under 32 bits)  (the option using CD4017 allowed me 10 bits)
6: The object doesn't have any electronic in it apart from the LED (+battery, res, etc)/ marker / Whatever other solutions.

So, here is the main question:
How can I track and identify a small object from far, using LEDs (which I thought was the best way) that will have the smallest possible price to implement

The two options I had were:
- the MCU + 4 leds and dependencies.
- a "hard coded" electronic path from CD4017...
- If anyone have a marker solution that can handle this, please let me know. As far as I know, it can't be done.

Example:
detecting a dice and its orientation, 2-3 meters away, 80 different dices.Oh and there is 10 dice in the screen.

[dannyf]

connect them to a battery by hand. cannot possibly be cheaper than that.

[jpauclair]

connect them to a battery by hand. cannot possibly be cheaper than that.

They have to blink an id..  1,1,1,0,1,0,1,0  each bit being around 25ms.

[exmadscientist]

It's going to depend a lot on what else you have in the system. An LED driver like the LP5521 is tiny and requires extremely little power, but needs to be configured by an I²C master. If you have one of those, great, you're done. If not, you might as well just go with your favorite tiny MCU.

Something to think about is how you're going to program these things. Soldering individual jumpers is all fine and well for prototype runs, but assembly houses aren't going to like building 100,000 boards all with different jumper patterns. They'd rather just program something... so now that tiny MCU is starting to look pretty good again.

[jpauclair]

It's going to depend a lot on what else you have in the system. An LED driver like the LP5521 is tiny and requires extremely little power, but needs to be configured by an I²C master. If you have one of those, great, you're done. If not, you might as well just go with your favorite tiny MCU.

Something to think about is how you're going to program these things. Soldering individual jumpers is all fine and well for prototype runs, but assembly houses aren't going to like building 100,000 boards all with different jumper patterns. They'd rather just program something... so now that tiny MCU is starting to look pretty good again.

Well, my solution with cd4017 doesn't include any MCU. Nothing at all. no I²C, no communication.

But my bad, I should have specified, I only wish to have a few permutation (< 30 ) (even tho the 4017 have 10 bits)
So this would mean 30 different PCBs... which is not such a big deal if there is thousands of each.

[nowlan]

Dont know about cheapest, but sounds very similar to how the digital dice kits work.
4017+555+diodes.
http://circuitdigest.com/electronic-circuits/digital-dice-circuit-using-ic-555
http://www.eleccircuit.com/electronic-dice-circuit-using-cd4017/

[jpauclair]

Some Taiwanese 4 bit MCUs are sub 10 cent. Cheaper than CD4017 from a reputable western manufacturer in small quantity.

Any brands and/or datasheet ?
I'de be curious to learn about these

[Wiljan]

Hi.

So you want to send 8 bit per Led x 3.

I would guess that you want some how to detect the ID number of each PCB with eg. a video camera. Then you will need to have a kind of sync pattern to know the the ID start over again.

Like having all 3 led to be off at he same time and then your combinations of LED must always have a least 1 LED on to know the it's not the sync pulse.
Or use 1 of the LED's only for sync signal

Will you use 1Red, 1Green, 1Blue led?

What are your demand for battery / psu ... standby power, wake-up etc.?

If you are using video camera ... you will need to have the LED in sync somehow with the frame rate else you will have mixed signals in each frame.

Anyway it just a thought, since we do not know the use for you project, but it sounds interesting 

I  think I would go for a CPU to make it possible to adjust functionality even after PCB production and for sure the smallest footprint and lowest stand-by power

[mikeselectricstuff]

10f200 is pretty cheap, especially with Microchip's pre-programming service, though for high-volume there are probably cheaper, more obscure options from the Far East.
Also look at Silego's Greenpak devices

[dannyf]

They have to blink an id..  1,1,1,0,1,0,1,0  each bit being around 25ms.

that doesn't fundamentally change the answer: put some copper stripes on a board and swipe the wires across it. with a weak power source, you just need 3 leds + a hand.

no solution can be cheaper than that.

[tszaboo]

I wonder if those melody generator IC's are still available to buy. You might be able to use those to generate a pattern. Maybe one IC can even drive two LEDs...

[Watth]

They have to blink an id..  1,1,1,0,1,0,1,0  each bit being around 25ms.

that doesn't fundamentally change the answer: put some copper stripes on a board and swipe the wires across it. with a weak power source, you just need 3 leds + a hand.

no solution can be cheaper than that.

Maybe not that cheap if you include the salary of the person who's supposed to swipe the wire. As for power source, you should at least include 3 meals a day.

[westfw]

I wouldn't assume that the PIC10F200 is the cheapest microcontroller you can get.  Even at digikey, in Q1000, there's an EFM8 and some of the "braindead" ATtiny chips that are lower or nearly the same price.  In "very large" quantities, I'm pretty sure that price becomes something that you negotiate with a chip manufacturer, rather than something you look up in a catalog.

Don't forget that PCB area and component count also affect price.
With three outputs from a microcontroller and "Charlieplexing", you could drive 6 LEDs...

It looks to me like all the really cheap gadgets use COB technology - that would mean it's more a matter of what your manufacturer can do, and which chips they are comfortable dealing with.

But ... definitely go with a microcontroller.

[martinayotte]

STM32F030F4 can be a solution, using internal oscillator.

[AndyC_772]

Are the blinking LEDs the only thing on the board, or are there other devices already in the design that could be coerced into helping out? If you already have a microcontroller with a few spare pins, then perhaps it could save you needing another device.

Otherwise, I'd recommend a microcontroller too, and don't forget to include the cost of whatever scheme you use to set the ID on each board. Can you do it by wiggling a programming pin with an in-circuit tester? Fit a unique resistor value somewhere on the board, or a pattern of links? Unique firmware builds for each id?

[jpauclair]

Are the blinking LEDs the only thing on the board, or are there other devices already in the design that could be coerced into helping out? If you already have a microcontroller with a few spare pins, then perhaps it could save you needing another device.

Otherwise, I'd recommend a microcontroller too, and don't forget to include the cost of whatever scheme you use to set the ID on each board. Can you do it by wiggling a programming pin with an in-circuit tester? Fit a unique resistor value somewhere on the board, or a pattern of links? Unique firmware builds for each id?

The LEDs are the only thing on the board!

[exmadscientist]

The LEDs are the only thing on the board!

Then this topic isn't really "cheapest ways to blink LEDs", it's "what's the cheapest microcontroller?". Just use a bloody MCU. You're not going to do smaller or better or cheaper than that, not for any reasonable level of performance. (Except maybe, if your volumes are really large, you could go to one of the (Chinese?) manufacturers and ask for a customized part.)

I also strongly agree with the people asking how you configure this thing and how you delimit the start and end of a blink code... details like that are often what make or break solutions being viable. What's your plan there?

I think part of the reason people are a bit confused by your device is that it, well, doesn't make much sense. Just three blinking LEDs, blinking 32 possible 8-bit codes and nothing else, doesn't seem particularly useful for anything. Not that that's a problem for a project -- got to start somewhere after all -- but it doesn't mesh with the whole high volume manufacturing angle. You'd probably get better feedback by giving the whole picture, or at least more of it.

[dannyf]

it, well, doesn't make much sense.

that's why my idea of contact stripes + leds only makes perfect sense and is the perfect solution here. you cannot possibly find anything cheaper.

[donotdespisethesnake]

You can get blinking LEDs, so clearly the cheapest way is to ask the manufacturer for whatever duty cycle you need.

In general, cheapness is a function of volume, and cost tends towards the material cost.

[donotdespisethesnake]

it, well, doesn't make much sense.

that's why my idea of contact stripes + leds only makes perfect sense and is the perfect solution here. you cannot possibly find anything cheaper.

You cannot possibly find a suggestion more stupid.

I mean, there is trolling, and being a dick, and not much difference.

[zapta]

Option 2: Using a 555 timer with 3x CD4017, and "physically" link each "1" to matching pins of the cd4017.
for the ID: 11101010, we would link pin 0,1,2,4,6 to the led, the others would do nothing.

How do you connect multiple outputs to a single led? Are these open drain outputs?

Also, a MCU will allow to encode 0 as a short pulse to make it easier to count successive 0s.

And if you use low duty cycle own,  you may even be able to save the three resistors.

[ralphrmartin]

Have you considered using linear feedback shift registers?

http://inst.eecs.berkeley.edu/~cs150/sp03/handouts/15/LectureA/lec27-6up

[voltsandjolts]

You say the only electronic parts on your 'board' are there to just flash an identity code on some LEDs.
Are you really sure this design isn't suited to RFID or QR code stickers?

[KL27x]

I agree this questions seems to be "what is the cheapest microcontroller," on the surface.

But I see some curious things inside cheap Chinese electronics using more components, jumper wires, and even THRU HOLE stuff (on phenolic boards with no mask) for no good reason... As if someone out there has stockpiles of thru hole parts and free labor, which if you live in China, I guess you have access to this sort of thing. I imagine this stuff is being designed specifically to use overstock/available components up, or something like that.

Maybe OP is hoping to find someone with that kind of knowledge/experience. 

[jpauclair]

Option 2: Using a 555 timer with 3x CD4017, and "physically" link each "1" to matching pins of the cd4017.
for the ID: 11101010, we would link pin 0,1,2,4,6 to the led, the others would do nothing.

How do you connect multiple outputs to a single led? Are these open drain outputs?

Also, a MCU will allow to encode 0 as a short pulse to make it easier to count successive 0s.

And if you use low duty cycle own,  you may even be able to save the three resistors.

Well the trick I was thinking about with the CD4017 was to link multiple pins together, going to the same led.
Since the CD4017 just iterate on all pins, you can light up the led for each "up bit" all pins going to the led are binary 1, and other pins are not going to the led... so the led shut down (0) off.

[jpauclair]

The LEDs are the only thing on the board!

Then this topic isn't really "cheapest ways to blink LEDs", it's "what's the cheapest microcontroller?". Just use a bloody MCU. You're not going to do smaller or better or cheaper than that, not for any reasonable level of performance. (Except maybe, if your volumes are really large, you could go to one of the (Chinese?) manufacturers and ask for a customized part.)

I also strongly agree with the people asking how you configure this thing and how you delimit the start and end of a blink code... details like that are often what make or break solutions being viable. What's your plan there?

I think part of the reason people are a bit confused by your device is that it, well, doesn't make much sense. Just three blinking LEDs, blinking 32 possible 8-bit codes and nothing else, doesn't seem particularly useful for anything. Not that that's a problem for a project -- got to start somewhere after all -- but it doesn't mesh with the whole high volume manufacturing angle. You'd probably get better feedback by giving the whole picture, or at least more of it.

I guess you are right.. now it begins to sound like this.. but its really not!

Let's get back to main objectives:
1: I want to get an identification (ID) for a very small object.
2: I want to be able to get that ID from far (2-3 meters)
3: I don't wanna get into bluetooth and that sort of things... I want it to be  < 0.2$
4: I could use QR code, or any visual marker, but the area is very small, so at 2-3m, it worth nothing.
5: the information I need to get is only an ID (let's say under 32 bits)  (the option using CD4017 allowed me 10 bits)
6: The object doesn't have any electronic in it apart from the LED (+battery, res, etc)/ marker / Whatever other solutions.

So, here is the main question:
How can I track and identify a small object from far, using LEDs (which I thought was the best way) that will have the smallest possible price to implement

The two options I had were:
- the MCU + 4 leds and dependencies.
- a "hard coded" electronic path from CD4017...

And now .this option:
You can get blinking LEDs, so clearly the cheapest way is to ask the manufacturer for whatever duty cycle you need.

In general, cheapness is a function of volume, and cost tends towards the material cost.

More details on this one please?

So here we are, with alot more details.
By the way, thank you all for helping me on this one! 

[mikeselectricstuff]

Why 4 LEDs not one ?

How about a single RGB LED - these are super cheap nowadays, though  if you care about power efficiency, white is the way to go.

[mikeselectricstuff]

Does this need to be human readable or can you use a device to receive it?

[jpauclair]

Does this need to be human readable or can you use a device to receive it?

By a 40fps+ camera

[jpauclair]

Why 4 LEDs not one ?

How about a single RGB LED - these are super cheap nowadays, though  if you care about power efficiency, white is the way to go.

Only to prevent occlusion

[mikeselectricstuff]

Does this need to be human readable or can you use a device to receive it?

By a 40fps+ camera

Automatically, or manually viewing a recording ? If the former, could there be more than one device in view, and what sort of range of light & background conditions ?
Do you have control of the camera type?
How much control do you have of view angle of camera and required emission angle ?
What is the worst-case latency - this will determine how often you need to send the pattern and hence power - or is there some trigger you can use to activate transmission?
How big do you really need the address space to be ? If you really need 32 bits then you'll be making enough to afford to do a custom ASIC!
What is the reason you say 3 LEDs ?
 

[mikeselectricstuff]

Why 4 LEDs not one ?

How about a single RGB LED - these are super cheap nowadays, though  if you care about power efficiency, white is the way to go.

Only to prevent occlusion

So why did you say "independent" - surely to prevent occlusion you just need to blink simultaneously, though for peak-power reasons you may choose to do them one at a time if latency isn't an issue.

[jpauclair]

Why 4 LEDs not one ?

How about a single RGB LED - these are super cheap nowadays, though  if you care about power efficiency, white is the way to go.

Only to prevent occlusion

So why did you say "independent" - surely to prevent occlusion you just need to blink simultaneously, though for peak-power reasons you may choose to do them one at a time if latency isn't an issue.

Haha you are right, again my bad!
I encode the "side" of the object. so they are, indeed, independent..!
So the ID is similar, with 2 bit reserved to "side"

[mikeselectricstuff]

..and what sort of quantity are you envisaging building?

[jpauclair]

Does this need to be human readable or can you use a device to receive it?

By a 40fps+ camera

Automatically, or manually viewing a recording ? If the former, could there be more than one device in view, and what sort of range of light & background conditions ?
Do you have control of the camera type?
How much control do you have of view angle of camera and required emission angle ?
What is the worst-case latency - this will determine how often you need to send the pattern and hence power - or is there some trigger you can use to activate transmission?
How big do you really need the address space to be ? If you really need 32 bits then you'll be making enough to afford to do a custom ASIC!
What is the reason you say 3 LEDs ?

Here is a lot of questions! I'm guessing you know what you are talking about.
1: Multiple devices in view
2: IR leds.
3: Let assume we don't have much control over camera. Camera will give us a steady 40fps
    Ideally, I would like it to be compliant with any camera type... but while in dev, I'm thinking of OpenMV or CMUCam
4: custom ASIC..? Isn't this like... reallyyyy expensive?
5: Let say 80 unique object, 20K units each?

[mikeselectricstuff]

4: custom ASIC..? Isn't this like... reallyyyy expensive?

It all depends on quantity - tooling/design cost is expensive but unit cost can be very cheap, so if your volume is high enough, the savings on unit cost pay for the tooling. Your functionality is simple enough  that design & tooling costs are probably relatively low (at a not-very-informed guess, probably 4 figures).

5: Let say 80 unique object, 20K units each?

So I assume you mean 20K units with the same ID, and 80 different IDs ? So 1.6 million total?
That could easily be within ASIC territory, as the functionality is so simple that even a tiny 4 bit MCU will have a lot of wasted die area.
Probably also worth investigating COB assembly.

Finding the cheapest MCU is probably the way to go, which would probably be mask-rom. I don't know the economics of maskroms these days ( and how they compare to flash or OTP) , but I suspect you'd want to have one maskrom and a way to code the ID on the PCB, rather than a mask for each ID, but if the cheapest MCU turns out to be OTP or flash  ( or mask with some OTP) then code-per-chip type may be the cheapest route,
 
 If you're wire-bonding a COB you could use the bonding process to code the IDs on identical chips.
4 pins with a hi/lo/open option gives you 81 codes, but you could also potentially share the LED outputs, e.g. 3 pins that can be bonded hi/lo/open or to one of the 3 LED outputs gives 216 codes.
You probably want to include some error protection in the code, depending on how critical error performance is - parity, crc, ecc. or if you will always be receiving multiple copes, simply requiring 2 or 3 identical codes.

Probably the main thing that will drive the design is power - what battery size, what life do you need and what options do you have to turn off/on or save power when not needed. Also what latency is acceptable, to determine teh transmit rate.

One option you have with IR LEDs , as they have low Vf, is to run from 1.5v, so one battery option is an alkaline button cell ( LR44 etc.) , assuming you can find an MCU that runs on 1.5v  - probably doable for a maskrom part - ISTR Epson and EM Microelectronic do low voltage mask MCUs.

The advantage of alkaline is you can get a lot more peak current out of them than lithium coin cells, so will be able to pump plenty of power into the LEDs



 

[mikeselectricstuff]

If standby power turns out to be critical, and ASIC may also offer advantages over an MCU.

If it's transmitting a lot, then choice of coding is very important for optimal power draw. A scheme like IrDa, where the code is in the gaps between very short pulses would be optimal, but you'd need to have a well-defined camera spec to design the coding scheme - i.e. exposure time long enough to capture a pulse, and inter-pulse gaps chosen with regard to the frame rate.

[alexanderbrevig]

Though, if you're using CV for tracking and ID then the off period will imply some predictive tracking (probably with hidden markov model and bayesian networks) this will make it fairly limited how many devices you can track... I don't know anything about this scenario, if they're moving or what the purpose of all of this is.

Any chance you could tell us more about the scenario / the problem you're trying to solve? Sounds interesting

[mikeselectricstuff]

Though, if you're using CV for tracking and ID then the off period will imply some predictive tracking (probably with hidden markov model and bayesian networks) this will make it fairly limited how many devices you can track... I don't know anything about this scenario, if they're moving or what the purpose of all of this is.

Any chance you could tell us more about the scenario / the problem you're trying to solve? Sounds interesting

Makes a big difference if the objects are  moving - latter would make life harder, more so with multiple objects.
 

[ralphrmartin]

If you are using a camera, why do you need leds at all? Why not just put printed patterns on the objects? Indeed, do you need markers at all?

[mikeselectricstuff]

If you are using a camera, why do you need leds at all? Why not just put printed patterns on the objects? Indeed, do you need markers at all?

Perhaps a code printed on a retro-reflective label, with a light source at the camera. required field of view would dictate practicality.

[ralphrmartin]

If you are using a camera, why do you need leds at all? Why not just put printed patterns on the objects? Indeed, do you need markers at all?

Perhaps a code printed on a retro-reflective label, with a light source at the camera. required field of view would dictate practicality.

Computer vision algorithms can be pretty good at markerless object recognition / tracking these days. As usual, knowing more about the application would help...

[ChunkyPastaSauce]

If you are using a camera, why do you need leds at all? Why not just put printed patterns on the objects? Indeed, do you need markers at all?

Wondering that as well...  data is static... 20,000 pcb assemblies, enclosure method, batteries.... really needed?

Another alternate maybe passive rfid tags.. similar readable range you would likely get out of something like the CMUcam, ~0.10usd per tag, removes complexity of imaging system, line of sight not needed, hardware and software is off the shelf vs custom dev

[jpauclair]

If you are using a camera, why do you need leds at all? Why not just put printed patterns on the objects? Indeed, do you need markers at all?

Perhaps a code printed on a retro-reflective label, with a light source at the camera. required field of view would dictate practicality.

Computer vision algorithms can be pretty good at markerless object recognition / tracking these days. As usual, knowing more about the application would help...

Example: detecting a dice and its orientation, 2-3 meters away, 80 different dices.
If anyone have a marker solution that can handle this, please let me know. As far as I know, it can't be done.
Oh and there is 10 dice in the screen.

[jpauclair]

If you are using a camera, why do you need leds at all? Why not just put printed patterns on the objects? Indeed, do you need markers at all?

Wondering that as well...  data is static... 20,000 pcb assemblies, enclosure method, batteries.... really needed?

Another alternate maybe passive rfid tags.. similar readable range you would likely get out of something like the CMUcam, ~0.10usd per tag, removes complexity of imaging system, line of sight not needed, hardware and software is off the shelf vs custom dev

Camera is a must.

[jpauclair]

If you are using a camera, why do you need leds at all? Why not just put printed patterns on the objects? Indeed, do you need markers at all?

Perhaps a code printed on a retro-reflective label, with a light source at the camera. required field of view would dictate practicality.

Very intersting! I did not think of that!
I think the problem would come with distance. Just like classical markers, the "pixels" won't be readable at 2-3 meters. (on tiny markers)
But still... nice idea

[ChunkyPastaSauce]

Example: detecting a dice and its orientation, 2-3 meters away, 80 different dices.
If anyone have a marker solution that can handle this, please let me know. As far as I know, it can't be done.
Oh and there is 10 dice in the screen.

Identification and orientation is a classic use of image recognition, certainly can be done. 

Just like classical markers, the "pixels" won't be readable at 2-3 meters. (on tiny markers)

Markings placed on 10 diced sized objects should be readily readable with appropriate cam and lens optics from 3 meters

[jpauclair]

Example: detecting a dice and its orientation, 2-3 meters away, 80 different dices.
If anyone have a marker solution that can handle this, please let me know. As far as I know, it can't be done.
Oh and there is 10 dice in the screen.

Identification and orientation is a classic use of image recognition, certainly can be done. 

Just like classical markers, the "pixels" won't be readable at 2-3 meters. (on tiny markers)

Markings placed on 10 diced sized objects should be readily readable with appropriate cam and lens optics from 3 meters

I'de be happy to know more about it, but lets assume we have an approx 1280x720 40fps cam.

[nctnico]

Without knowing what kind of lense is being used and what kind of field you want to capture the resolution and framerate aren't going to help. I also think that trying to capture blinking lights in a videostream is going to be very hard because you'll likely also need to recognise and track the object across several frames BESIDES detecting it in the first place. A high resolution and framerate can actually be a bad thing according to my experience with computer vision. Depending on the application a big size QR style encoding (possibly with color if lighting is good enough) could be a much better bet. It will be easier to make the tags (just go to a print shop and have them designed/made) and the computer vision system will be allowed to drop a whole bunch of frames without getting into trouble.

[jpauclair]

Without knowing what kind of lense is being used and what kind of field you want to capture the resolution and framerate aren't going to help. I also think that trying to capture blinking lights in a videostream is going to be very hard because you'll likely also need to recognise and track the object across several frames BESIDES detecting it in the first place. A high resolution and framerate can actually be a bad thing according to my experience with computer vision. Depending on the application a big size QR style encoding (possibly with color if lighting is good enough) could be a much better bet. It will be easier to make the tags (just go to a print shop and have them designed/made) and the computer vision system will be allowed to drop a whole bunch of frames without getting into trouble.

Just so you know, I've worked on quite a lot of image processing and visual marker recognition/tracking.
In this case, having such small surface and such a big range, it might not be the best guess.
I will try it soon for sure, but let's just stick to the main question about the LEDs if possible.

I already have a working prototype.
It can detect multiple LEDs with unique ID, using a standard cheap 1280x720 camera. Multiple time per seconds.
What I need is the "hardware part" (circuit / components)  and is there any way to crunch it to a simpler design, that would cost almost nothing to make.
How to design the most simple circuit that will be able to "blink" LEDs with a specific pattern.

[mikeselectricstuff]

Without knowing what kind of lense is being used and what kind of field you want to capture the resolution and framerate aren't going to help. I also think that trying to capture blinking lights in a videostream is going to be very hard because you'll likely also need to recognise and track the object across several frames BESIDES detecting it in the first place. A high resolution and framerate can actually be a bad thing according to my experience with computer vision. Depending on the application a big size QR style encoding (possibly with color if lighting is good enough) could be a much better bet. It will be easier to make the tags (just go to a print shop and have them designed/made) and the computer vision system will be allowed to drop a whole bunch of frames without getting into trouble.

Just so you know, I've worked on quite a lot of image processing and visual marker recognition/tracking.
In this case, having such small surface and such a big range, it might not be the best guess.
I will try it soon for sure, but let's just stick to the main question about the LEDs if possible.

I already have a working prototype.
It can detect multiple LEDs with unique ID, using a standard cheap 1280x720 camera. Multiple time per seconds.
What I need is the "hardware part" (circuit / components)  and is there any way to crunch it to a simpler design, that would cost almost nothing to make.
How to design the most simple circuit that will be able to "blink" LEDs with a specific pattern.

If you are certain that LEDs are the answer, you already have a few potential answers - lowest-end MCU or ASIC, probably a COB assembly. No other solution will approach the all-in cost in the quantities you're talking about.
Possibly die-bonded LEDs if the optics work out - maybe die bonded LEDs on the PCB combined with an injection-moulded light guide to direct the light in the required directions. A moulding like this could also be used to do things like holding the battery, retaining the PCB etc.   
 
You want to be talking to the sort of people that make flashing LED badges & toys, but you do need to think carefully about the power issue in order to specify the design sufficiently well.

[nctnico]

Perhaps this question is better asked to a manufacturer of these kind of gadgets. There are too many variables where solution A is cheaper/better then solution B or vice versa. This also has to do with the production techniques available to a manufacturer and their experience.

[Someone]

Balancing a dice to the precision users expect while potting all this circuitry and a power source, you've got a long road ahead.

A high resolution and framerate can actually be a bad thing according to my experience with computer vision.

They need to be suitably matched, a camera might not even be the best solution if the transmitters are an open ended part of the solution (IR channel with CDMA or other strong telecommunications codings designed for mass transmitters). But the OP is drip feeding and says the camera is a fixed requirement. I'd be guessing at this point its validation for casinos and they want to leverage the existing camera infrastructure (at which point modifying the dice is insane).

Since the dice sit for some time while people observe the result it'd be a good candidate for a single frame (HDR exposures perhaps) at a high enough resolution to pick out dice face across the required field of view. Shoehorning this backwards to a camera specification is the wrong way to go about it.

[ebclr]

0.07 USD per piece

http://www.emc.com.tw/eng/database/Data_Sheet/8BIT/EM78P173N.pdf


https://world.taobao.com/item/536258162819.htm?spm=a312a.7700714.0.0.H5dZUO#detail

[jpauclair]

0.07 USD per piece

http://www.emc.com.tw/eng/database/Data_Sheet/8BIT/EM78P173N.pdf


https://world.taobao.com/item/536258162819.htm?spm=a312a.7700714.0.0.H5dZUO#detail

Wow...
This is looks amazing!
Did you try it? How did you find this one exactly?

[ebclr]

Just type MCU and ordered by price, and have several  supplier who can offer this product

https://world.taobao.com/search/search.htm?_ksTS=1475462058516_330&spm=a21bp.7806943.20151106.1&_input_charset=utf-8&navigator=all&json=on&q=EM78P173NSO14J&callback=__jsonp_cb&cna=Fb46ECHjIXICAbrne69e0gIM&abtest=_AB-LR517-LR854-LR895-PR517-PR854-PR895

[ebclr]

Also another option a litle more expensive 0.33 USD but western friendly

http://www.st.com/content/ccc/resource/technical/document/datasheet/4f/65/a3/d2/dc/56/46/d2/DM00060484.pdf/files/DM00060484.pdf/jcr:content/translations/en.DM00060484.pdf

https://world.taobao.com/item/39262418157.htm?spm=a312a.7700714.0.0.3aC6Uy#detail

[mikeselectricstuff]

0.07 USD per piece

http://www.emc.com.tw/eng/database/Data_Sheet/8BIT/EM78P173N.pdf


https://world.taobao.com/item/536258162819.htm?spm=a312a.7700714.0.0.H5dZUO#detail

If that's the price for a packaged OTP device, I wonder how much cheaper bare die would be.
 

[mikeselectricstuff]

Balancing a dice to the precision users expect while potting all this circuitry and a power source, you've got a long road ahead.

A high resolution and framerate can actually be a bad thing according to my experience with computer vision.

They need to be suitably matched, a camera might not even be the best solution if the transmitters are an open ended part of the solution (IR channel with CDMA or other strong telecommunications codings designed for mass transmitters). But the OP is drip feeding and says the camera is a fixed requirement. I'd be guessing at this point its validation for casinos and they want to leverage the existing camera infrastructure (at which point modifying the dice is insane).

Since the dice sit for some time while people observe the result it'd be a good candidate for a single frame (HDR exposures perhaps) at a high enough resolution to pick out dice face across the required field of view. Shoehorning this backwards to a camera specification is the wrong way to go about it.

It would certainly be cheaper to add a suitable camera.
If this is dice application, then for power management, some sort of motion detector should work well - probably something like a slightly loose ball contacting pads on the PCB. Just need to arrange the mechanics to work in any orientation. Doable but will need quite a bit of design & test work.

[amyk]

0.07 USD per piece

http://www.emc.com.tw/eng/database/Data_Sheet/8BIT/EM78P173N.pdf


https://world.taobao.com/item/536258162819.htm?spm=a312a.7700714.0.0.H5dZUO#detail

If that's the price for a packaged OTP device, I wonder how much cheaper bare die would be.

Not quite the same but I've seen sub-$0.01 for 4-bit mask ROM MCUs in >10ku (not including mask costs.) That one is pretty cheap for an 8-bitter with 1K instruction words.

[Xenoamor]

Bit of an off the wall idea but have you considered using an IR transmitter (it doesn't have to be an IR led though)? Something with a 555 timer connected to a LED and then you can just vary the components to change the frequency of the LED
you could then use the frequency to determine which device is which

You'd just be paying for a few resistors/capacitors and a 555 timer

[mikeselectricstuff]

Bit of an off the wall idea but have you considered using an IR transmitter (it doesn't have to be an IR led though)? Something with a 555 timer connected to a LED and then you can just vary the components to change the frequency of the LED
you could then use the frequency to determine which device is which

You'd just be paying for a few resistors/capacitors and a 555 timer

But that wouldn't get you any power management, and varying the frequency wouldn't give many ID options once you take the camera framerate into account

[dannyf]

Cheapest way to make 3 LEDs blink a specific pattern ID

How many EEVBLOG posts does it take to find the Cheapest way to make 3 LEDs blink a specific pattern ID?

[westfw]

Quote

It would certainly be cheaper to add a suitable camera.

What is "state of the art" for bar-code or QR code scanning via hi-def camera?  The smallest possible QR code apparently encodes 5 numeric digits...

[Someone]

Quote

It would certainly be cheaper to add a suitable camera.

What is "state of the art" for bar-code or QR code scanning via hi-def camera?  The smallest possible QR code apparently encodes 5 numeric digits...

Its not simple to define, you are limited in the resolution of cameras for a given field of view which places a lower limit on the resolvable detail. IR ink on a dice would be an improvement over just measuring the existing pattern, but its a cost trade off between the volume of consumables and the number of measuring devices needed. Solutions for customers measuring a few units with their numerous phones is radically different to a solution for a single location measuring millions of things.

[Wiljan]

Interesting article on Binking Led the LSI way
http://hackaday.com/2016/10/13/blinking-an-led-extreme-edition/

[dannyf]

that's too extreme.

so far, no one has presented a cheaper alternative than my swiping-leds-through-copper-stripes approach.

[alexanderbrevig]

[...]so far, no one has presented a cheaper alternative than my swiping-leds-through-copper-stripes approach.

I'd like to know how much it would cost to hire 40 people (given they manage to use one hand to swipe), have them in green suits and put in the time to make sure their intervals are OK to get detected by the CV algorithm.
To be cheap is not the same as being fuctional. The title says blink a specific pattern after all. 

[tszaboo]

[...]so far, no one has presented a cheaper alternative than my swiping-leds-through-copper-stripes approach.

I'd like to know how much it would cost to hire 40 people (given they manage to use one hand to swipe), have them in green suits and put in the time to make sure their intervals are OK to get detected by the CV algorithm.
To be cheap is not the same as being fuctional. The title says blink a specific pattern after all. 

Dont feed the troll.