Mathematical Teaser?

'Fraid I'm still a bit sleepy. Don't understand this bit:

"But if I allow a re-positioning of the sensors to sense a possible 5 positions (say for different customers and their specific applications) that results in a possible 21 codes. (I've just down grade that from 25, as I don't want all 4 sensors to see 1s as it could be fooled by a solid black bar)".

_{Also got flummoxed by finding it'd changed between reading it and hitting "Reply"!}

Any danger of a sketch? Pretty please?

Oh, pull yourself together man.
Imagine a circuit board with holes for 5 sensors, but you only install 4.
(The positioning could be customer specific)
As far as the rest of the world is concerned there are 5 valid positions for the black or white bits, only you and me know that there are only really 4 sensors)
If it makes it easier, you can imagine 5 doors with only 4 goats behind them (or squirrels)
Oh dear, now I need a lie down.
Del

I'll see if I can do a sort of picture.
The 'O' s represent the positions which the sensors may occupy and the ^ is the sensor.

OOOOO
^^^ ^

Or for a differnt customer and differnt set of valid barcodes.

OOOOO
^^ ^^

Of course we'd end up with some barcodes common to both arrangements, but I'm probably envisioning each customer would only want say 4 valid codes, and this sort of scheme allows more unique codes.... _{I think}
Del

Ooooh nice chart.
Although the blue is a tad pale on my monitor.
Del

As I look at JohnDG's sheet and consider your comment "...as I don't want all 4 sensors to see 1s as it could be fooled by a solid black bar", could not a code of three ones in a row have a similar issue?

In a linear barcode the outermost lines define the edges and have no value within the code.

Nope...
If you present the machines sensor array with a solid black or solid white it will see 4 1s or 4 zeros. We disallow them as naughty codes... I think you know where you've got to go and sit.
If you go quietly and think about what you've done we'll say no more about it.

I've deliberately avoided the many pitfalls of barcodes by contriving this scheme whereby a coded object will be placed ito a receptacle (which lines it up) on the front of the machine, if the code is recognise an operation is performed (which, for the sake of argument we shall assume is the dispensing of food to captive squirrels. The different codes are different foods... oh boy, you should see the gloop we serve up for 1010 )
With this arrangement there is no scanning or movement, it's hopefully simple robust and reliable.
Del

Okay, I'm with you. The coded squirrel food cups will be registered to the reader. Thus the scenario I put forward would never occur because the read limits are defined.

I'm not sure you have avoided a pitfall. Your cat food scanner has sensors at positions 1-2-3-4. Your squirrel food scanner has sensors at positions 1-2-3-5. You put cat food 1-2 into the squirrel scanner, which thinks it is squirrel food 1-2.

Yes there will be some common codes which need weeding out, which is why I was actually asking about how the number of codes increases with increasing numbers of 'blank positions' in the original post.
I'm trying to find a sensible compromise between number of sensors and number of position, so that if I lay out a circuit board I'd have plenty of versatility.
I think 4 sensors is plenty... maybe I should have 8 positions? That's what the actual Q is about.
Del

If squirrel food 1-2 needs a different code for cat food 1-2 your only solution is to find out how many uniquely different foods are to be coded and how many sensor combinations are not allowed, adding the two together. You then put the appropriate number of sensors on all the boards, with no blanks. You can save on the number of sensors only if you are sure to separate the cat food from the squirrel food

Ah yes but ...
If we design this product for one customer, who doesn't know what the uptake will be and hasn't actually specified the number of products in his range of squirrel food.
We can also make it potentially interesting to an unknown number of other customers with unknown numbers of products.
So you see it's all guess work.
In the real world we get approached by customers with vague "wouldn't it be nice if" ideas and no hard specification.
We end up trying to second guess which of these ideas are worth running with.
Customers eh?
Can't live with 'em, can't live without 'em.
Del

I'm glad I have retired from the real world. If were still living in it, I would expect the squirrel food company to have at least some idea of its current product range and I would then offer a specification based on double the size of that range (blaming binary digit logic, of course). If the firm were then so successful that the next year they wanted a bigger machine, you've obviously got a happy customer, and you charge a premium for the upgrade.
I don't know what size your production runs are, but for maximum flexibility on your part it would probably be cost-effective to design a sensor board with numerous spaces for sensors with jumpers across the output of the sensors not used in the current production run.

with numerous spaces for sensors .
Ah, 'numerous'... that's clarified it then.
Yeah between you and me, this specific customer is the classic guy who can only tell you what he doesn't want and whats wrong... never what he actually wants.
Del

I suppose it goes without saying (like the taxicab in The Phantom Tollbooth) but unless you tell the computer reading the 4 outputs from your sensors which receiver locations the sensors are plugged into, or have different physical plug-in locations for each arrangement, the output from the 4 sensors will always only be 16 distinct values (of which you allow 10 valid codes). In other words, how does the computer (or the intermediate circuit board) know which set of 1s and 0s any given sensor is reading? It needs to know how to distinguish a 4-sensor arrangement from a 5, or 6 or higher number configuration.

_{/...just sayin'...}

Ha and ho!
The computer will indeed be none the wiser.
But the cusomer's squirrel feed cups will be coded to match the physical arrangement of the sensor elements. Whereas the next customer with a different product (cat food?) will have his cups coded to match his machine and thus can lock in his product to his cups, and prevent the wrong type of cat food being dispensed into the wrong cup, and stop cat food being fed to squirrels and vice versa.
The system is about feeding the correct bulk product into the correct cups which are of course only supplied by the vendor.
I expect you are all stoatally confused by now.

Effectively it allows the same basic, simple system to be sold to multiple customers each of whom can have their own unique few codes for their products (coded on their cups/containers), to ensure the correct product gets dispensed into the correct container for the correct purpose.
So Squirrel polish doesn't get dispensed into a cat lubricant application
Del

Well, this stoat understands stoatally.

But he wants his supper.

Kudos to AP#1

http://en.wikipedia.org/wiki/Gray_code

Lots of handy analysis tools on the wiki for gray code

Gray code
by bit width

Have you considered staggering the sensors vertically as well as horizontally? This can effectively double, etc the codes available. allows for two code lines to be sensed.

Have you considered staggering the sensors vertically...
Sort of, I've considered a vertical orientation of the circuit board as well as the horizontal. Staggering would be fiddly for froduction, and I always consider ease of production
Del

Hi Del and all, I don't understand what's all the fuss about bits and noughts. This is a quite simple thing for some logic-gate calculations. Sorry, can't do it right now since I'm at work and should be dealing with other "gates".

As bar code readers are really cheap nowadays, why not use them? There are many bar code systems around that can be printed easily with any reasonable modern printer.

A possible non optical method would be RFID, which is also within the price range of even amateurs nowadays.......and is not fooled by dirty labels either......

I personally would not even start to go in the direction you are going.....sorry. I strongly believe in not trying to invent the wheel again.

Whatever you decide to do, proofing it against possible errors generally takes 3 to 4 times longer than the initial invention.

Been there done that and GOT the T-Shirt!!

Both Bar Codes and RFID have error correction already built in.....

RFID was sent from heaven......some say!! (The inventor died last week at 89 years old!)

Don't tease the kitty.
Integrating someone elses kit into a commercial product is a nightmare, you are at their mercy regarding mechanic changes, pricing, availability and countless other considerations. Designing your own gives better flexibility, imunity from copying, make the component costs less and often the assembly cheaper as it can be designed for production.
Other than that i totally agree with you!
Del

I fogot to mention specifically, if you decide to go your own way, you must consider using at least a parity mark as well, it will catch most errors of "reading" if a parity error is generated when a bit is read incorrectly, but it is not infallable.

Furthermore as parity is only the very simplest of error detection, you may want to add some LRC checking as well. Both must be really simple to add using a single PIC.....

Keep us informed of what happens......

Thank you - I was wondering why not a bar code reader while I was reading this thread.

So going back to the question

000x
001x
011x
010x
110x
111x
101x
100x

and

00x0
00x1
01x1
01x0
11x0
11x1
10x1
10x0

actually equal the same number of unique non-error identities and they are additive.

So a four hole PCB with three stuffed = 6 uniques, the same four hole PCB with three different holes stuffed = 6 uniques...so the total equals 6+6+6+6.

So we are back to 2ⁿ minus your strikeouts where n = number of stuffed holes, the unstuffed hole simply 'drops out'.

All of the above depends on how you actually implement in hardware tho

What if you space out the sensors in a non linear fashion with 5 sensors?:
^^^4^6^
123^5^7^^^11
use one position for indexing and read the other positions. If 7 then read 123 & 5. If not 7 then reject 123 & 5.
Or use only 3^5^7^^^11
Build your board so you can put four sensors in one of 21 positions with non linear spacing and you can have unique code reading with no errors.

Blimey that would give plenty of scope.
4 in 7 gives
7x6x5x4 /4factorial = 35 posible positions by my reckoning (probably wrong... my maths is rusty)
And each position would still have 10 codes within that position!
Sound like 4 sensors in 6 positions should do the job.
Del

Sorry, but that does not save on the number of sensors. You will need at least a block of sensors for the range of products and a block of sensors for the manufacturers, each complying with the rules for legal codes. This is so that the sensing mechanism can detect whether the product's manufacturer is the correct one, and that it is squirrel food rather than cat food.

I was waiting for someone to spot that gem. It is the only senible way to go and if the product had another dimension you add 2 or 3 more sensors for, say, colour or a taste quality like bitter, neutral, sweet.

Happy days, Del.

Sleepy

Of course it saves on sensors.
The product cup* locates in a fixed location in front of the array of possible sensor holes (say 40 in this case).
If there are 40 possible positions for the sensors they could simply be located in consecutive blocks of 4 to give 10 completely unique unambiguous cases.
Customer 1 uses locations 1-4 for his codes.
Customer 2 uses locations 5-8 for his codes.
Customer 3 uses locations 9-12 for his codes.
.
..
...
Customer 10 uses locations 37-40 for his codes.

This is an extreme example, and if I don't use consecutive sensor positions I can avoid such a cumbersome arrangement.
Del

* assume a rectangular cup that is acurately located into the machine to line up with the array of possible sensor holes. A round cup is difficult to align consistently.

This argument is going to get rather circular unless we refine the specification of the machine.

Should it provide a detection and positive identifying output for every product of every manufacturer? If yes, then it needs sufficient detectors to distinguish items from the sum of the product ranges, and the arrangement of the detectors is irrelevant.

If no, then is the same machine to be supplied to different manufacturers, each customer receiving a machine with a unique sensor arrangement which correctly identifies items from that product range and returns a zero on the others? If so, then what is the point? What is the likelihood that a squirrel food manufacturer will insert a cat food item into his machine? Indeed, what is the likelihood that the squirrel food manufacturer and the cat food manufacturer will use the same cup?

If the machine is to be supplied to a pet food retailer, then we are back to the first situation, and the number of sensors must cope with the full range of squirrel and cat food (and the retailer would not thank you for not using barcodes).

We are in danger of getting into overthink here.
The machine will be sold to customer A who wants it to only work with his suitably coded 'cups'.
However to make production economically viable we may want to sell the product to customer B, C and D etc.
These customers may have vaguely similar products in the same size 'cups' and each will want their machine to only work with their coded 'cups'.

The reasons for coding are that the machine may deliver say 4 different 'flavours' and these must be delivered into the correct cups for the correct application.
The reason for differentiating between customers is to avoid Customer C stealing customer As account.
Del

How likely is that? I've been wondering why the squirrel food and cat food need to have different labels.

Are Customer C and Customer A known to one another? Do they go around spying on each others dispensers? Do the canteens let them in???

Aren't square cups hard for humans and squirrels to hold?*

Haven't you already gone into overthink?

*Cats don't have opposable thumbs so it doesn't really matter to them.

Oh Rose,!
I have your Chrissie present...
Here
Del
_{<scampers off really really fast to hide in most secret of secret cat nests.}

You want me to repair the door on your not-so-secret cat nest???

_{<reaches in and pulls Del out, expertly removing his claws from the wood....and smiles. Scene fades....>}

I have to agree fully, I see no benefit from the OP's ideas over and above RFID or Bar Codes...and a lot of developement/fault finding time saved.

Ha ha ... you said RFID.
I've already explained why it's better and cheaper to design and build your own. (#23)
If you want yet another reason, just look at the inventory costs and cash flow issues.
It's the same when people want things to 'talk to their laptop'...
Yeah great in theory until the next generation of hardware and software hits the market with smaller connectors and software that isn't backward compatible.
Maybe if you really want to discuss the economics of manufacturing using bought in sub assemblies it would make for an interesting thread?
Any how this is a tad off topic, ans I don't expect the project to go ahead anyway, I don't think there is the volume. It was meant to be a bit of a brain teaser/question.
Del

Think it has been done.

Grey code.

I'm still trying to figure out what you did with that other goat!