QR decoder parsing differences

[seedywee]

QR codes appear to be parsed differently in different QR decoders. In the Basen and Gobel online decoders, as well as the Android LiFePOQR decoder, the QR code eg 07HCBC1P22G06AC700002596 indicates a manufacturing date of 7 Jul 2022.

However, on sites such as Docan Power, Energie Panda and Second Life Storage, the same QR code indicates a manufacturing date of 7 Dec 2020.

My experience is the same with 16 pcs of Higee 120Ah cells purchased over three years. Which decoder is correct?

 

[Whats_per_question]

A QR code is just bytes, with a particular encoding (and represented graphically). That might be text, symbols, binary, characters from various ASCII code pages - it all depends on the author's decisions.
This is the same issue with computer files - the file is only unambiguous if the file format limits the encoding or states the encoding in the file itself.

To answer your question, you would have to find info from the author of the QR codes (which i presume is the cell manufacturer) about what encoding they used - and it seems obvious that the assumptions that Basen/Gobel/LiFePOQR made are different than the assumptions that Docan/Energie/SLS made.

My unqualified guess; the QR code contains (among other data) an integer that represents the number of days since an epoch, and Basen et al use a different epoch than Docan et al.

The same issue happens with timestamps between various systems - some might be milliseconds since 1/1/1970, others of lower precision might be seconds since the same epoch, or maybe seconds since 1900 - the decisions the authors make could/will make a big difference to the precision of a timestamp, and the amount of space (bytes) it takes up.

On a side note ... if you want to drive yourself mad, learn about time and timestamps - and realise that nobody really know what the time is.

 

[zcskywire2]

Code decoding standard, informative but not super understandable:

GB/T 34014-2017 English Version, GB/T 34014-2017 Coding regulation for automotive traction battery (English Version) - Code of China

GB/T 34014-2017 English Version - GB/T 34014-2017 Coding regulation for automotive traction battery (English Version): GB/T 34014-2017, GB 34014-2017, GBT 34014-2017, GB/T34014-2017, GB/T 34014, GB/T34014, GB34014-2017, GB 34014, GB34014, GBT34014-2017, GBT 34014, GBT34014

www.codeofchina.com

Code breakdown:
1-3 - unique manufacturer Id, 07H = Higee
4 - battery type, C = cell
5 - Chemistry, B = lithium iron phosphate
6-7 - manufacturer product code, not unique across manufacturers, C1 =that version of the Higee 120ah LFP cell
8-14, manufacturer custom info. Space left for manufacturers to put what they want, decoding only available properly for eve cells, p22go6a

15-17- Date of manufacturing. This is where at why things are confusing, they do not give in the English translation a format for the date just that 880 equals Aug 31st 2018. So people do not know if that is m/y/d or y/m/d. That is the difference you are seeing between the code readers above.
Days run from a-z (skipping a few) then 1-0
Month is 1-9 then a-c
Year is 8-9 then a-z


18-24 cell serial number for that day

Now I have an easy solution to the question now that we're are far enough away for the epoch


This was manufactured this year and purchased direct from the manufacturer with the code D7C
D is out side of the month range of 1-c so the code has to be in Y/M/D format which makes the bottom set correct

 

[Whats_per_question]

Yay for good deductive reasoning. Top marks to @zcskywire2

That would have been easier if the cell manufacturer had the info in an open format easily available.