My customer is using 01.21.0000. I will tell them to upgrade and test. Thanks!

I have created a code39 barcode with Narrow to Wide Ratio=2 and 10 mils, so it has the same size than my customer's and MC65 can read it without issues. Paper is white and printer is a good laser printer. Problem still is that Intermec can read these awful barcodes rather well (actually as good as MC75A), I personally saw it yesterday. Can I upgrade pixdll "by hand" and see if this improves readings? Where can I get latest set of scanning dlls to upgrade my terminal (on BSP17)? Since MC65 is Qualcomm I do not think I could extract them from a MC75A, implant on MC65 and expect it works! Thanks!

this is quiet old OS, did you run th3 test on MC65 with A1 BSP31.2? if the issue persist with A1 OS release we can try to update the pixdll , I can send you version 5.15.4.113 it to you over lync for example .

Thanks! BSP 17 is the one I have on "my" MC65. I first have to check which version my customer is running on their units.

Which imager is in the MC65 you are testing with?  Is it the SE4500 SR or DL?  Does the MC3190 have the same imager as well?

Thanks Riad! I can perfectly read your example with a BSP17 MC659B-PD0BAA00100. However, it is larger than my customer's barcode, so it has "more mils". I still can't decode original with the same terminal. Also, please note that background colour is yellow and this seems to have a negative impact on decoding.

I'm able to read all Code 128 barcodes from the sample sheet with my MC65 (2.31.0002). The smallest one (6 mils) is difficult indeed but readable from the fixed distance - still slow, may take 2-3 second to decode, just cross your fingers and wait. Cannot read Code39 samples though. That's said - work with BU, open CPR if needed. They were extremely helpful in our project for Russian Post. There was a lot of issues with MT2000 performance on more or less dense 1D and 2D barcodes (not decoding, long decoding (extremely long I would say when you may already give up and put the unit on the table and suddenly it gives the data from the barcode) so we went through a series of custom pixdll-s and eventually cured them all.

dpi of the scan is very low couldn’t read the barcodes sample with any blockbuster terminals or scanners, I built a barcode using the same data and even more dense than yours , then I tested it with mc75 and also mc65 both were able to decode it without an issue , the PixDll in mc65 is 5.13.8.2 , they were couple of new versions with some enhancement to improve decoding performance but without seeing the issue am not able to do the test and let you know the result . The below was from bruno  I would look at a few settings that might affect performance on a code 39 : 1) Trioptic code must be disabled . Trioptic code is a code 39 variant and always has six characters. 2) TLC 39 must be disabled. This is a code 39 base code used in the telecom industry. It can dramatically affect code 39 performance. 3) Linear Security should be set to Short or codabar for best aggressiveness. 4) Code 39 Redundancy. Should be disabled. 5) Security should be set to 1

missed to attach the sample

I have seen the same issue less than a year ago while using MC65 imager to decode very small Code 39 and EAN-13 barcodes (cosmetics distributor). It was very hard to decode them at all. We played a lot with the DataWedge settings but nothing worked out. Customer eventually switched to Intermec CN50 as it did much better in decoding the symbols.

I have original copies, I flat-bed-scanned them (at two resolutions and contrast), but I do not think they could be readable at all.

I am afraid customer will eventually move to Intermec's CN50 too. They have successfully tested them. Unless we can make them move to MC75A...

Thanks! I have disabled all the symbologies on both MC65 and MC75, except code39. This SPR# 22330 is about SE4500 instead of very MC65. MC75 has SE4500 too and works -more or less- well. I suspect issue has more to do with softw implementation of decoders on MC65 than actual hardw problems.

can you attach the code39 barcodes you used during your test ?

Furthermore, I have a customer with extremely poor quality code39 barcodes, and very dense too. They have MC65 with SE4500 imager, the very same than MC75A. Well, with this imager they are simply unable to decode these barcodes. MC65 with laser can eventually decode them, if they are lucky enough to aim a line without printing problems. Anyway, it takes ages to decode. MC75A, same SE4500 imager, same DataWedge config than MC65's, can easily decode them, as long as the distance is not too long. The only solution we can provide is telling them to get these barcodes fixed. Replacing MC65 with MC75A seems not be an option. But I suspect these fellows might move to Intermec. Uh, did I not mention that CN50 can read them very well? LI4208 can too, I tested it and it's really impressive.

possible, SPR 22330 can help with code39 - DDC now working to get drivers better. Also, be sure that you have disable trioptic39 barcode

Which BSP is installed on your MC65? I run test here to compare (MC65 BSP31.2 Vs MC3190 BSP41 ) both had same performance in my opinion , I was able to decode all barcodes from your sheet only the last which seems to have ratio issue mostly with the first space in the barcode when it was pasted on word . Comparing the imagerkit decoder library (pixdll) between the two devices it’s true that mc3190 contains newer version ( 5.13.8.2 MC65 Vs 5.14.9.2 mc3190) but this didn’t show any difference in the performance . I created the last barcode (see attached ) again 6mils and I can decode it properly with the both terminals . Following link https://support.symbol.com/support/search.do?cmd=displayKC&docType=… Pixdll version 5.15.4.113 is posted, you may give it a try. Regards, Riad
 

sample codes used.