Interesting. There was a time when I had muggle mode turned off for a few build targets, because there wasn’t enough space left in the ROM. But I don’t think I sent any of those to Hank. The current versions have muggle mode again, because I was able to reduce the size enough for it to fit again… and I sent those to Hank a few days ago.
Looking at my logs, I sent Hank D18 firmware from 07-18 and 11-24. Muggle mode was cut out from 09-24 to 11-23. I’m guessing he may have grabbed updates from my site without mentioning it. Keeping things up to date is great, but not all of those builds were tested as much as I’d like for widespread use.
Also interesting. I put the 11-19 and 11-20 builds up hoping to get help with testing… but they were not intended for production use. These builds included some major changes to the kernel code, so I consider it high-risk. The testing has all gone well so far, but because the changes were large and deep, I was not planning to use any of those changes in production until they had been proven stable for a few weeks.
The good news is that everything so far suggests the kernel changes work correctly and did not break anything. But I think I may need to find a way to mark builds as “dev” or “stable” to avoid any dev builds going to production.
This is true. However, we don’t necessarily know that the drivers and firmware shipped with each light are the ones which were created for that specific light. For example, the D4S was shipped with Anduril for a while instead of RampingIOS V3, and I think it may have used the D4S V2 driver and firmware. Additionally, if the D1 has the tenclick thermal config, I wonder if it might be using a D4 V2 driver instead of the original D1 driver.
That’s a big part of why I originally wanted the version check mode to be … very detailed. I was hoping it could individually identify every build of the firmware, not just the date when it was built. This would allow one to check whether a D1 shipped with a D4 V2 firmware, for example. But it’s not easy to encode a long version string with a blinking light… at least, not in a way humans can easily parse.
So… it sounds like some unexpected versions of firmware may have been used, sometimes even on models they were not intended for. It should generally still work, but some of the details might be a little weird. Like, the ramp shape might be a little skewed, or the thermal response might be a little too slow or fast. But this shouldn’t cause any big issues.
As for tenclick thermal config, it would probably be good to have that on all Emisar builds… but it hadn’t really come up. Ever since adding factory reset, there hasn’t been much need for people to access the thermal config mode. Factory reset calibrates the sensor to 21 C.