Hello,
Is it possible to derive the date of manufacture from this information?
This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
Dear Craig -
the marking on the top of the part may be helpful if you can take a picture of that or reply back.
I will ask about the serial #, i would assume here that it is possible to track that way too, but i don't want to guess - please allow a day or so to get back to you on this.
6A1R is on the top of the part just under the window.
I would like to be able to determine the date of manufacture programmatically by reading the serial number register.
Craig -
I have some information from the R&D team - i need another day or so to figure out how to communicate it to you correctly. Sorry for the delay.
Craig -
Here is the breakdown of how you can use the information for determining date of manufacturing from the part.
For this example, I read back registers from a device I have which was manufactured on Oct 6, 2016:
0xFB ==> 0x028D ==> 0000001010001101, bits 15-11 are always 0, bits 10-6 stand for month, when binary is converted to decimal; bits 5-1 indicate day, also in decimal, bit 0 is MSbit of year
0xFC ==> 0x099C ==> 0000100110011100, bits 15-12 are last four bits of year, which when converted to decimal, are the last two years of the date. The rest of the bits do mean something, but are of no use to you here.
BITS |
BIT 15 |
BIT 13 |
BIT 13 |
BIT 12 |
BIT 11 |
BIT 10 |
BIT 9 |
BIT 8 |
BIT 7 |
BIT 6 |
BIT 5 |
BIT 4 |
BIT 3 |
BIT 2 |
BIT 1 |
BIT 0 |
FB |
N/A |
N/A |
N/A |
N/A |
N/A |
MONTH |
MONTH |
MONTH |
MONTH |
MONTH |
DAY |
DAY |
DAY |
DAY |
DAY |
MSb of Year |
|
0 |
0 |
0 |
0 |
0 |
0 |
1 |
0 |
1 |
0 |
0 |
0 |
1 |
1 |
0 |
1 |
|
|
|
|
|
|
Decimal = 10 => Oct is 10th month |
Decimal = 6th day
|
Decimal = 16 (2016) |
||||||||
FC |
b of year |
b of year |
bit of year |
LSBit of year |
N/A |
N/A |
N/A |
N/A |
N/A |
N/A |
N/A |
N/A |
N/A |
N/A |
N/A |
N/A |
|
0 |
0 |
0 |
0 |
1 |
0 |
0 |
1 |
1 |
0 |
0 |
1 |
1 |
1 |
0 |
0 |
Craig -
also, if it helps, here is Saleae capture of getting the bytes correctly, then outputting on UART after concatenating the 4 bytes together into 32 bit number, according to their ranking, then bit masking each five of the bits of interest at a time (I AND'ed the complete 32 bit value with 0x7C00000 for the month, 0x3E0000 for the day, 0x1F000 for year), and then right shifted each output accordingly (22 bytes for month, 17 bytes for day and 12 bytes for the year.
in my case, i output like this on the UART
HDC1080_Read out FB_FC_for_DoM_calc_then Read Temp Hum _1sec intervals.zip
Thanks again, Josh. Those Saleae devices are really slick! I've been using an older poor man's device - Digilent Analog Discovery II.
Hi Josh,
Me again!
Question on the year portion of the serial number. Shouldn't this be 7 bits? Otherwise, we could only go up to 2032?
Thanks,
Craig
Craig -
Yes, I see this would only take us to end of 2031. I asked the folks in design what the plan might be for after that. One thought I had was -as the part was RTM'ed in 2015, 2014 (01110b) and before (down to 00000b) could stand in and allow for another 15 years...properly documented of course, if and when that time comes. Will let you know what i hear back.
Craig -
My original thought was correct - the idea here is in 2032 it would be programmed to 00000 and that would indicate 2032 to us.
Perfect. I was hoping it would be something like that. I can factor that rollover into my algorithm.
Thanks again Josh.