D4V2 doesn't do direct Moon once in a morning

Unheard · 2019-11-07T08:48:23.000Z

This is really strange. Since a few days my D4V2 refuses to start despite audible feedback from the button. A second button press always works.

In the morning, I always start the Emisar in direct Moon, i.e. press and hold the button. Few days ago I was wondering why nothing happens, clicked it a second time and it started up normally. Since then, I have this problem every morning. I’m unable to enforce it. No matter where on the button and how fast or strong I press it, the Emisar starts normally. It’s really just once a day that it stays off.

This is an early D4V2, flashed second Anduril version after muggle mode bug was uncovered. Battery is Samsung 30Q, LEDs are SST20@3000K.

mitsuki08 · 2019-11-07T15:38:19.000Z

This happens to me sometimes. Pick it up and click it to turn it on to the memorized mode but nothing happens. I shrugged it off as an improper click but I’m pretty sure I heard the feedback from it as well. I bought mine a few days before the D4V2 was released in case it’s relevant. Not sure which Anduril version it has but it’s still the one shipped with it. It has the 2 mode lockout.

Valynor · 2019-11-07T15:52:32.000Z

This is likely the software bug ToyKeeper mentioned in another thread.

Basically Anduril checks for the battery level and other stuff every x seconds and if you try to click your light on in that exact moment it won't react. Happens to me too every couple days/weeks depending on how often I use it.

The fix for this implies a larger rewrite of the Anduril code and will probably take a while. I'm not very happy with this bug either.

ToyKeeper · 2019-11-19T08:24:09.000Z

Unheard:

This is really strange.

Yeah, I hear you.

Also, I think I fixed it.

I rewrote quite a bit of kernel-level code in FSM over the past week or so, and I can’t get it to miss a hold-from-off event any more. I’m still testing to make sure it all works correctly, but results are good so far.

The changes also seem to fix a bunch of other issues which only happened rarely. Basically, I got rid of a ton of race conditions by rewriting some deep foundational code with the goal of making it more thread-safe. Interrupts can and do happen at any time, so I refactored how those work in order to ensure the important parts of the code will only happen in the right order.

It shouldn’t affect anything in the user interface… except occasional weird behavior shouldn’t happen any more. Or at least, if it happens, it should be a lot less frequent.

Since I modified a lot of core parts of the code, I plan on putting this through a lot of testing before I consider it stable. Not sure how long that’ll take. The code is published though, for those who want to try it. I’ll put up some compiled versions soon too.

Unheard · 2019-11-19T08:53:38.000Z

Thanks, TK :-). Please drop a link when you have compiled versions.

ToyKeeper · 2019-11-20T00:02:08.000Z

I went ahead and put the full set of builds online. Not all builds have been tested, since it would take forever to fully test everything on dozens of different models… but it’s all there if anyone wants it.

The ones I’ve tested are the ones which are easy to reflash. And I haven’t done the thermal testing yet. In general though, everything seems good so far.

Unheard · 2019-11-20T08:11:12.000Z

First tests: Temperature overshoots by more than 15K.

Initial temp 21 something Celsius (IR measured and blinked out), final temperature 67 something celsius (IR measurement). Limit should have been 52. Adjusted two times.

When it’s cold again, I’ll calibrate the sensor manually, and again set the limit temperature. Hope I just have a mistake somewhere.

Before, temperature went some Kelvin over the limit, but never more than 5.

Edit: Verified. Have you increased the offset from 30 to 40?

ToyKeeper · 2019-11-20T09:03:45.000Z

Nope, I didn’t change any thermal thresholds. The ADC code runs twice as often now though, so I doubled the delay timers which control how often the new values are actually used. The effect should still be pretty much the same, but could still be different in subtle ways.

Overall, the thermal behavior shouldn’t have changed… except hopefully less prone to sudden strange adjustments. I think in the past it was occasionally getting a voltage measurement instead of temperature, which could cause it to think the light was suddenly getting very hot.

It’s a bit difficult to quantify the actual temperature though, since I don’t have anything to measure and log it with. All I’ve got here for measuring thermal behavior is a phone with Zak’s ceilingbounce app, and touching it to feel if it’s hot. So it’s really helpful to hear about your results!

Unheard · 2019-11-20T09:41:35.000Z

Let me know if I can do something. Unfortunately, I cannot log temperatures. I have a GM550 IR thermometer and a GM1020 luxmeter.

And I’m still not sure if I didn’t have a mistake. Someone else tried the new binary?

ToyKeeper · 2019-11-20T19:05:28.000Z

I’m not aware of anyone else who has tried it yet. At least, not on a device which has thermal regulation.