Talk:MSI Barcode

I have removed referances to Mod 11 check digits for MSI/Plessey codes. The result of a Mod 11 calculation will always be a number between 0 and 10 but MSI/Plessey can only encode numbers 0 to 9 so Mod 11 check digits make no sense. --Hooper114

You're right, there was an error in the formula - the check digit is calculated by subtracting the modulo 11 of the weighted totals from 11, so that will always be a 0 to 9 digit. I've reverted your edit and fixed the error. Thanks! --Canley 22:07, 22 May 2007 (UTC)[reply]

Sorry, but I don't agree. Now you have check digits from 1 to 11. As an example try encoding 24463342. S becomes 24336442. X = 4+12+12+15+36+28+8+6 = 121. C becomes 11 - (121 MOD 11) = 11. At the other end if you encode 64030540 it gives S = 04503046, X = 76, C = 1. If you took C-1 as the check digit you would still be back to check digits between 0 and 10. The problem is with any algorithm including Mod 11. --Hooper114

I've looked a bit more into this, and it looks like I misinterpreted the Barcode Island reference, which is actually phrased "The modulo 11 checksum is that value which must be added to the result of step 3 in order to arrive at a total of 11", which does work for 10 and 11 (1 and 0 respectively). I found another reference at IBM [1], which states it in a more technical way: apply the modulo 11 function again to the result after subtracting from 11, so the check digit for the examples you gave are: 24463342 = 4 and 64030540 = 0. I've checked all these by hand and at http://www.bokai.com/BarcodeJSP/applet/BarcodeSampleApplet.htm, and it works! Well done for spotting this. --Canley 13:03, 23 May 2007 (UTC)[reply]

This algorithm is getting more and more complicated! I agree that this clears up the problem with 24463342 and 64030540 (in retrospect I should have used shorter examples!), which now have check digits of 0 and 1 respectively - but try the new algorithm with 2211. X=23, C=10. So yet again you're back to having check digits between 0 and 10. The Bokai Barcode applet adds 1 and 0 to the barcode so that the check digit becomes two check digits and the whole thing becomes 221110. I would never have thought of that! While I agree that you now have three sources which agree with your algorithm, can this really be correct? Surely a decoder would read 22111 with check digit 0, work out that the check digit should be 2 and assume the data is corrupt? Unfortunately my barcode scanner (made by Intermec) only supports MSI with Mod 10 and Mod 1010 so I can't experiment to find out. Symbol Technologies (who took over MSI Data Corp in 1988 according to the New York Times archive) claim their scanners do support Mod 11 but don't say how. --Hooper114

Sigh, you're right again... I've put a verify tag on the Mod 11 section. As you say, even though it seems to correspond to several sources, even professional implementations of this algorithm seem to be incorrect. There is some mention in the IBM reference about a modifier byte which seems to determine whether or not a check digit calculation of 10 or 11 yields an error, or applies the modulo 11 function again. I'm not sure if that's anything to do with it, but it seems ridiculous to recursively apply the functions until you get a one digit checksum. I'll do some more research into this anyway... --Canley 00:24, 24 May 2007 (UTC)[reply]

On further reflection perhaps the Bokai applet is right after all. Take a look at https://docs.symbol.com/KanisaPlatform/Publishing/693/ADC-00596_f.SAL_Public.html. Perhaps the trick is that the scanner needs to be set up for fixed length reads. In the case of 221110 the scanner would be programmed to expect 4 digit numbers, then assume anything after 4 digits was the check, and would read correctly. In a warehouse situation the barcode makers and barcode scanners would likely be the same people, so this would work - all they would have to do is pick a barcode length and stick to it. --Hooper114

Should be mentioned that Mod 10 is not very good

I think it should be mentioned that Mod 10 is not good as a check digit as it only checks the last number. i.e.

3897984 1234 98294 726784

all make the check digit 4 so the code could be scanned completely wrong and as long as the last digit and the check digit were scanned correctly it will validate. —Preceding unsigned comment added by 92.233.245.130 (talk) 14:10, 7 May 2008 (UTC)[reply]

Missing step in section 'Mod 10 Check Digit'

I think the section 'Mod 10 Check Digit' is possibly missing a step. Step 5 has "C = Z mod 10", where Z = 2726. Then it has C = 4. I believe 2726 mod 10 = 6, not 4. Maybe the article should read "C = 10 - (Z mod 10)". I think this is right, but I am not positive, so I didn't want to edit the page. —Preceding unsigned comment added by 66.162.185.110 (talk) 16:09, 19 October 2007 (UTC)[reply]

You are quite right. There seems to be an error in that section. It appears to me that the 'Mod 10 Check Digit' algorithm described in the IBM reference is identically the same as the algorithm described on the "Luhn algorithm" article. I'm betting that IBM is right and Wikipedia is wrong -- this time :-). Rather than correct the algorithm here, I will delete that entire section, and replace it with a very brief example, and a link to the "Luhn algorithm" article (which seems to get it right) for more details. (That's the appropriate Wikipedia:Summary style, right?) --68.0.124.33 (talk) 01:08, 5 April 2008 (UTC)[reply]

Bar ratios

There is no information on how to print an MSI code. What are valid bar ratios between wide and narrow bars? --Nowic (talk) 14:14, 25 February 2014 (UTC)[reply]

A thin bar is one bit width and a thick bar is two bits width, and there are no more than two adjacent bits of the same binary state in the mapping, so the ratio is always going to be 2 to 1. --Canley (talk) 01:49, 26 February 2014 (UTC)[reply]