This whole thing is quite amazing.
Good going, internet!!
Thanks for the feedback Elix! Working on code right now, actually.. Hope to be debugging first prototype hardware in the coming week.
This really does help greatly if you have a chance to answer that question- I have limited data on non-US models. It seems the vast majority have both connectors, and two people so far have indicated that they have A17 only and A18 only. I may just have to figure out a way to include both connectors. The trick will be doing it elegantly without over-complicating and over-costing. I'm actually postponing that decision for now and working on functionality. "undo" functionality and thinking about selectable reset points. (in case your set actually does need to be set to the first correction point rather than all the way back a zero.) I don't have any evidence that this is necessary however, so I'm also wrestling with whether or not to spend time and effort on those features. Part of me says that should wait for v2. Part of me thinks people may not be happy if they buy one and 6 months later a newer version exists.. ...
based on that information alone, here's an absolute stab in the dark (ha!)..
0x13c5 = 5061 hours
0x4788 = 18,312 minutes (or, 305.2 hours)
0x114a = 4426 power cycles
The total hour count would then be 5366.2 hours, close(r) to your 1st estimate.
0x004a = 74 hours
0x012c = 300 minutes (5 hours)
0x006c = 108 power cylces
The total hour count there would be 79 hours, also close(r) to your 2nd estimate.
The question is, how sure are you of your 1st and 2nd hour-count estimates?
IF the middle two bytes are minute counters, then you should be able to re-read your values after even, maybe, 15 minutes, and see the middle two digits changing. Of course, this is a total guess and I could be absolutely wrong! :) It would make sense at least to count minutes, since loosing so many fractional hours over thousands of power cycles could really get any compensation algorithm thrown off pretty bad...
EDIT- to add:
Alternatively, the middle two bytes could be bit-split.. it only takes 6 bits to count up to 63 (enough to count up to 59 minutes and then reset back to zero). The remaining 2 bits in the fourth byte could roll into the third byte, as follows:
0x4788 = 0100_0111_1000_1000
six LSbits = 00_1000, or 0x040 = 8min
remaining 10 bits = 0100_0111_10:
padded to 16bit = 0001_0001_1110 = 0x11E = 286 hours
So your two data points would be:
0x13c54788 = 5061hrs + 286hrs + 8min = 5347hrs, 8min
0x004a012c = 74hrs + 4hrs + 44min = 78hrs, 44min
or the reminder 2 bits could stand alone:
= 5061hrs + 71 hours + 2 hrs + 8 min = 5134hrs, 8min
= 74hrs + 1hrs + 0hrs + 44min = 75hrs, 44min
Just goes to show that we really need more information. Being able to watch it "tick" would be great.
But all of this begs the question, do we need to know? I suppose that all depends on if the anti-aging algorithm is really necessary or not.. And we may need a statistically large sample size to know that. :(
Ha ha ha.. no worries Miro.. I had forgotten about you mentioning the counting in 15minute increments. That actually makes a lot more sense to be because EEPROMs have finite write cycle limits (usually either 10,000 or 100,000 writes over their life), so storing minute-by-minute would be a bit extreme. Hysterically, I also forgot that you were reading from the service menu before reading the eeprom values. It's obvious now that I had no idea was I was talking about.
In a week or two when I hook back up to my TV, I'll try to remember to make some successive measurements.
sorry to have gone so far into left field with my last post..
Huh. Well times have changed. At least on the M24C64, the write cycles have been bumped all the way up to 4 million. I had no idea they'd gotten that good.
I'm not positive this is the same model, but avforums had the following picture posted on one of their threads.. It looks like there may be a plastic rectangle in the upper right region of the picture? That may be a service port? If anybody has a service manual for the gt20 we could find out where they are pretty easily.
Yes, thanks! Taking a quick glance, on the GT20B model a least, A17 and A18 have been renamed CN0101 and CN0102. They're located in the top-right region of the A-board, as shown in the two diagrams (taken from the service manual). One diagram indicates where the A board is in relation to the back of the TV, and the other is a diagram indicating where on the A-board the two connectors are located. I think, looking at our previous images a few posts back, that the little black rectangle is in the right location to be concealing the access to these connectors.
Thanks Gov! Are you checking my site (see link in sig line)? I was on a business trip all last week.. The conference went fantastic, but I didn't have a single chance to work on the PMCv1. I got most of the internal flash storage technique working on Sunday night though. the I2C communication has a bug, it works in debug mode, but not in full speed mode. I'm pretty sure what I need to fix, and I've got that on my list to do next. Wait, this should all be going on my site.. :)
Anyways, things are still moving along. I had hoped to give myself a month, and have really tried hard to keep that, but it may slip some. Life tends to do that when it's a side project. My wife doesn't want it dragging on forever though (neither do I), so I'm trying to get at least some work done every week.
I'll post another update later this week. It's a busy work week though, so it may be later than sooner. But progress is being made.
Well I'm officially reliably reading data from the TV directly after power-up. I'll update my site next week with a full update because I'm going to be working on it more over the weekend. Here's the most recent values I read tonight:
0x177B 0x7E90 0x12DA
However, the service menu indicates the following:
Time: 6027:0 Count 4844
In Hex, 6027 is not 177B but rather 178B.
In Hex, 4844 is not 12DA but rather 12EC.
Hours count is off by 16 hours, the middle bits may account for some of that (don't know yet).
The power cycle count however is also off by 18 cycles, which is interesting.
Did I read somewhere that the hours and power cycle counts reported in the service menu are not from the panel eeprom but rather somewhere else (peaks, perhaps)? Maybe that accounts for the difference.
Well, it's late, and we have a lot going on tomorrow. So this will have to do for now.