Are you both using the same firmware?
The pre-production meter would lock in depending on the AC and DC components. If you have a cheap power supply with a lot of ripple for example, the meter may actually read correctly.
V1.02 original (no autoranging patch)
Strange. You would think it would do it or it wouldn't. I am not sure what sort of regression testing is being ran on the patched code. Maybe the patch has something to do with it.
Yeah, it was a regression.
The original problem was that AC/DC mode operates by switching the meter mode every measurement and caching the result, to mix in when measuring the other mode. So you'd get:
1. read 5.5000V DC, store as 55000 counts. Autorange decides to range up.
2. switch to reading AC, read 00.000V, add previous DC counts to show 55.000V. Autorange decides to range up.
3. switch to reading DC, read 005.50V, add previous AC counts to show 005.50V. Autorange decides to range down.
4. switch to reading AC, read 00.000V, add previous DC counts to show 00.550V. Autorange decides to range down.
5. and so on and so on, literally forever.
The obvious way to bring the meter back is to input a DC value that's > 4000 and < 55000 counts, which explains in Joe's video why it hunts starting around 5.0000V and comes back at nearly exactly 40.00V. Or, input an AC value that results in a value within that range after both a bogus addition and a correct addition (by the way, it's not addition, it's sqrt(AC^2+DC^2) which I don't entirely understand why), so autorange settles down. So yeah, it definitely can depend on the AC and DC content.
Anyway, they fixed this by adding a delay so it would show two measurements before autorange decided to act again, thus flushing the bogus cached counts. But my patch mashes that delay to 0 whenever autorange acts (vs. the user), giving the same situation. My apologies for the confusion, but I can't test anything due to the delay in the US meters. I'll look into either applying that only to the resistance range, or perhaps just not to AC+DC mode.