Cheapest way to make 3 LEDs blink a specific pattern ID

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