25-year old JNIOR and the battery is not dead

[Bruce Cloutier]

I just had to post this. Recently we were looking at the motivations in creating the JNIOR line 25 years ago. I have found four JNIOR-A from that era. We do a teardown in this blog entry https://jnior.com/the-edge-controller-turns-25/ . One of these still had the clock and files. The 23 year-old battery measures 3.048v! This is completely unbelievable. That battery is soldered in place. It is even on a module that we did not manufacture. So it is not a battery that we could have replaced even if we had wanted to. The one we reviewed in the article had like 0.3V on it.

The logs show that the last time, before this morning, it was powered up was 18 years ago. The clock had today correct. It was off by about 2-1/2 hours. We did the calculation and, assuming that the clock was set correctly back then, that is an accuracy of around 15 ppm. Exactly what is to be expected for a crystal RTC circuit like that.

I don't know what to make of it. I suppose we start charting voltage verses time?

And, yeah, JNIOR has been around THAT long. Long before Digital Cinema if I have my timeline right.

[Mark Gulbrandsen]

I have had similar luck with many Mini Desktops over the years. I did a tear down, bios update, and clean up of a Lenovo that had a date of 2009 in it last week. The battery was actually at .982 volts! and the clock had not stopped! It definitely needed a cleaning out though...

[Marcel Birgelen]

The 23 year-old battery measures 3.048v![/B] This is completely unbelievable.

I don't want to rain battery acid on your parade right here, but if that's an honorable achievement or not depends on what voltage it started back in 2003.

Still, a battery that didn't leak in 23 years alone is almost worth a separate award.

As for the "Digital Cinema" timeline: It's from before DCI. First "Digital Cinema" showcases of technology that eventually evolved into DCI, were as far back as 1999 and 2000. (Star Wars and Toy Story 2).

[Bruce Cloutier]

I don't want to rain battery acid on your parade right here, but if that's an honorable achievement or not depends on what voltage it started back in 2003.

Ha. Yeah, you are right. I should have mentioned that it is a primary lithium coin cell and not rechargeable. We use 3V and so I assumed that was what those were. I found the original Dallas schematic and it specifies "3V Lithium". So with that measurement, it is as good as new. But why?

You can see it in that article. The article is not promotional and so not an annoyance to read. So if you wonder what the first JNIOR was like. That was it. Worth a look. I would be happy to explain what has changed and why. That is, if you have any questions.

I developed a product in the 1990s that used a 3.6V cell. So that could have been the case and the current voltage would not have been so exciting. I remain baffled as to this case.

[Leo Enticknap]

Vaguely related to which, last Monday I had a third instance of the situation posted here and here, in that a Barco ICMP certificate battery that had been left for many years longer than the recommended replacement interval was still alive, and I was able to swap it out without losing the media block:

image.png

Note the dates that the original batteries were installed: March 29 (measured 2.93 volts on removal), November 14 (3.04), and now November 13, 2018 (2.99). And from the handwriting, it looks like all three were installed by the same person (my handwriting is so dreadful that I use printed labels; and I also use the first three letters for the month, to prevent any confusion between US and European date numbering conventions if the next person to handle this unit is not me).

Given that Barco claim that replacement is necessary every four years and that in the ICMP, the certificate is maintained by the battery constantly (i.e. not by mains power when the projector is on, so battery life is not affected by the proportion of time that the projector is powered up and down), the only explanation I can think of for these batteries lasting so long is that the Barco factory lucked out and got an unusually strong batch of CR2477s in early 2018, and were using them throughout the rest of that year. I've had ICMPs lose their certificates after well under four years (as in, we were only called when nothing worked and the red light came on) that came out of the factory later.

[Bruce Cloutier]

Obviously the results are statistical and we will get the outliers at the limit. In case of the JNIOR-A the battery runs through an elaborate battery manager that decisively switches to battery when power is removed. That also powers a RTC somewhere. So, as for luck, it would be a combination of really good battery and SRAM and RTC each falling on the really low standby power side.

With JNIOR-A and JNIOR2 (some of those Kodak had installed), a dead battery was bad news. While it didn't protect a critical ICMP certificate, all of the configuration plus the applets providing the website were lost. About the only thing that survived was the IP configuration, provided you "committed" that to Flash at some point. And, you only got to do that once. It was an adventure even for us to get a JNIOR-A up and running for the teardown. Then, naturally after the fact, I find one that is still good to go. Go figure?

Series 3 introduced the \flash memory area and thereby saved critical files. That model also let us introduce applications like cinema.jnior with which all of you are familiar. Series 3 batteries are all dead I would bet.

But now I am curious. There is a PCB revision planned and the battery manager from Maxim-IC has gotten so ridiculous in price that I pulled a circuit from 1995 that serves that purpose. That will cost about 10% of that stupid over-priced chip. I will analyze the standby draw and compare with the JNIOR-A.

[Harold Hallikainen]

The current drawn by an RTC is interesting. MANY years ago, I designed a product with an MK48T02 "TimeKeeper RAM." It had a 2 k byte static RAM and an RTC with a built in battery. There was a status bit to enable the RTC. There was another bit to "kick start" the RTC. The RTC oscillator was very low current and would not start on its own. So, it would be kick started to get it going.

Speaking of RTC, I really don't like using the typical RTC chips. Instead, I'd like to use a 32 bit or 64 bit counter that advances once per second. Then stanard C time routines convert this to whatever you want. In several recent products, I just to an NTP request on power up, then set a 32 bit software counter that is incremented every second. On the next NTP sync, the period register is incremented or decremented in the direction required to get the speed right. This all works towards my philosophy that the ideal design has zero parts (no RTC chip, no 32 kHz crystal, no battery, etc.). I recognize that this is not appropriate for every product, though.

[Steve Guttag]

Whatever you do, I wouldn't use whatever the CAT745 (Harold may know more about it) or the IMS3000 uses for its RTC. Sundials can be more accurate than them. I'm amazed at how far they can drift on their own, despite needing to be accurate.

[Leo Enticknap]

I've lost count of the number of times I've had to email Dolby with the subject line "Need clock reset patch for IMS3000, serial XXXXXX." It's at least once a month, and often more. At least with the cat745 you reset it from an out of budget state yourself using a command line script that I believe lets you bump it by an hour a year. With an IMS, you need the patch from them.

[Steve Guttag]

What's stupid is, once the drifty ones are identified...let them have an extra couple of minutes of slop. It's no worse than the CAT745 solution and, really, it isn't like I'd be asking for a 1-hour drift (The ability to play something not in your time zone...which is why they have the restriction).

However, once you've identified the IMS3 that drifts...congratulations...EVERY YEAR you get to repeat the exercise...right about at the same time of year.

[Marcel Birgelen]

Dolby and others should implement something like a "trusted NTP server", one that signs their packets with THEIR signature. Once the server receives those signed packages, it will instantly sync to that source. Nothing else involved, no stupid maximum drift.

I guess this would violate the current DCI security standards, but I'd say that this would be sufficiently secure and would avoid many headaches with out-of-sync equipment.

The other solution would be to invest in RTCs that actually work, instead of all the dirt-cheap solutions they implement nowadays. It's not like we're not able to build clocks that can run years in isolation with just minimum drift from a reference clock, but such a thing would cost a penny or two... For the price those things cost, you obviously can't expect that kind of quality engineering and hardware...

Ha. Yeah, you are right. I should have mentioned that it is a primary lithium coin cell and not rechargeable. We use 3V and so I assumed that was what those were. I found the original Dallas schematic and it specifies "3V Lithium". So with that measurement, it is as good as new. But why?

Maybe you found the infinite energy glitch, now just scale it up towards the scale of a nuclear power plant and you'll be infinitely rich.

You can see it in that article. The article is not promotional and so not an annoyance to read. So if you wonder what the first JNIOR was like. That was it. Worth a look. I would be happy to explain what has changed and why. That is, if you have any questions.

I developed a product in the 1990s that used a 3.6V cell. So that could have been the case and the current voltage would not have been so exciting. I remain baffled as to this case.

Some things can be amazingly energy efficient, but it's almost a lost art.

I still remember back in 2006, I was on a business trip to Barcelona for 5 days and I forgot my phone charger. It was a Nokia phone. The thing lasted all five days, including numerous phone calls throughout the day and still had a charge left when I arrived back home again.

Nowadays, you're lucky if your phone makes it until the end of the day on a full charge... Granted, a mobile phone evolved from embedded electronics that could barely power a modern toaster to something that would've been the fastest supercomputer back in the 1990s in the last 20 years, powered by a lithium battery with the amount of stored energy that would've been considered a landmine, back in WW2... but building real energy efficient hardware and software, like I mentioned, seems to be something of a lost art.

[Harold Hallikainen]

The CAT745 (and the USL equivalent) used a chip from Maxim that had an internal switch between main power and battery power. Unfortunately, the clock oscillator frequency was not the same between the two power sources. I suggested we have a correction factor based on how much time it spent in each state. But that proposal was not adopted.

The chip was not just an RTC. It also had the private key, a bunch of other security stuff, and inputs for the tamper switches. I don't recall how the key stuff worked, but it MAY have accepted data encrypted with the public key and output the decrypted data without the private key ever being revealed. The data decrypted with the private key would be the AES keys delivered in the KDM for the content. But, I was not deeply involved in the project, so this is just peripheral thoughts based on long ago.

This, again, is an argument for just using a seconds counter instead of having the chip count years, months, days, day of week, hours, minutes, and seconds. It's real easy to add an offset to a counter. Much harder if you have to convert everything to calendar values.

[Bruce Cloutier]

Speaking of RTC, I really don't like using the typical RTC chips. Instead, I'd like to use a 32 bit or 64 bit counter that advances once per second.

You are absolutely right. It should just be a 64-bit i millisecond counter.One that is atomically read and written if it is in a 32-bit (or 16-bit or 8-bit) machine. What the Renesas RX part has is the stupid watch circuit c1970. I know because I was developing uP that far back. You know, you write the year, month, day, hour and minute. each separately. So you need to stop the clock to get all written before something overflows and advances the next register before it is set. If you don't stop the clock then you have to be incredibly sly and detect the overflow and rewrite or reread it. Worse you cannot set the seconds. You can only reset those to 00. It just some royalty-free license-free bullshit silicon library they grab. They can't be bothered. The counter would even be a lot less acreage and power. Not to mention -- it is how we handle clocks in the real world!

They spend incredible hours and dollars fine tuning a processor instruction set and pipeline. Some amazingly complex thing and then they pepper crap all around it. Renesas even screwed up the UART initially and didn't provide a reliable way to check if the Tx buffer was empty. Duh. Quickly fixed that.

Given that, and its probably Dolby's problem, it was mine as well, if you don't select the load capacitors for the clock crystal properly, the thing will oscillate off center frequency. That would be either slower or faster but never right on. There are only specific pF values available. So basically you can never get it perfect. Then the supply chain can't get the crystal you use and so you stick another in that hasn't been tuned.

The JNIOR (Series 4 with recent JANOS) actually tunes the hardware clock and software clock (kept by the OS) each time it synchronizes with NTP. There are registers for that purpose in the RTC and JANOS. Dolby probably doesn't even realize that. When JNIORs synchronize (with a good NTP source) it can still be off up to 32 milliseconds. That is the time slice the OS uses. That is the latency in getting around to processing the NTP response. The difference is reported in (nn) parens in the syslog when the update occurs. I can watch multicast packets in the JNAOS network sniffer arrive on two JNIORs effectively simultaneously and the clock reported might be off 1 millisecond between them.

But nobody gives a crap about the clock on the JNIOR. Nor should they. The Series 3 batteries are dead. And if those are not configured to reach an NTP server the clock isn't just off. It can represent a whole different century.

Hardware that you own managing certificates being held hostage to a poorly designed RTC is ludicrous. But not surprising. It is only going to get worse.

[Harold Hallikainen]

Note that the clock issue on the CAT745 was not Dolby's fault. They just bought IMBs from USL and put their name on them. I think the Maxim part was one of very few available at the time that could handle all the security requirements. On clock speed, the previously mentioned MK48T02 "Timekeer RAM" had a register we could write to that would adjust the clock speed by dropping or double counting clocks early in the divider chain so you could finely tune the clock rate. I think that's pretty much always required due to component tolerances. Also as mentioned earlier, products like the IRC use a software counter on a 1 Hz interrupt using the processor RC clock, which is not very accurate. But, on each NTP update, the period register is bumped one count in the direction required to get to the correct speed based on the values we had before and after the NTP update. The IRC and CCR-100 use a similar method to keep the frame counter in sync with the server. Each time the server sends the IRC a timeline update, the updated time is compared with the time in the IRC. If they are close, an offset is stored, then frame count advances are either dropped or doubled in the local frame counter until the offset has been removed. The frame counter clock is crystal controlled, so we don't need to adjust the frequency since frame count updates arrive several times a minute.

[Leo Enticknap]

The CAT745 (and the USL equivalent) used a chip from Maxim that had an internal switch between main power and battery power. Unfortunately, the clock oscillator frequency was not the same between the two power sources. I suggested we have a correction factor based on how much time it spent in each state. But that proposal was not adopted.

That's interesting. I look after an 11-plex that was originally all cat745, installed in 2011: as of now, there are eight survivors. Given the high failure rate when replacing the batteries in those IMBs, the decision was made to leave the projectors on 24/7 after Dolby announced that no more recertifications would be possible. The only time they are ever powered down is to do maintenance C and D on the projectors (or unscheduled repairs). Their last new battery was in February 2019, and I would guess that those IMBs have run on battery power for 2-3 hours out of the last seven years at most. But they still drift significantly if they can't sync to an NTP server (which is often, because they won't accept the TMS, and often refuse to sync to 128.138.140.44 as well), so much so that I have to run the manual reset script once or twice a year.