Incorrect Timings in Test Strip Mode

[patrickmorrisphoto]

I'm running into the same issue that Torleif Husebø (commenter on your Part 1 blog post) is with the test strip timing. Essentially, it seems to be just repeating the base time for each step rather than incrementing it. Also, when looking at the values it's using for whole stops, it's displaying the following times, given a base exposure of 4s: 4, 8, 12, 16, 20, 24. If we were doubling the time, I would expect increments of: 4, 8, 16, 32, 64. Similarly, with half-stop and a 4s base exposure, I'm seeing: 4, 6, 8, 10, 12, 14. These are close, but given that the timer can achieve increments of 1/10s, I would expect these to be 4, 5.6, 8, 11.3, 16.

I'll take a look at the code, when I get some free time and see if I can help figure out what's going on. If I find the issue, I'll send up a pull request on the Git repository, if it allows. I'm no developer--though I am a software tester by trade and do a little bit of coding. No promises on being able to fix the code, but I'll see what I can do!

I'll upload a video of the behavior for you, as well, and attach it to this issue.

[patrickmorrisphoto]

Here's a video of the behavior I'm seeing: https://photos.app.goo.gl/aWQn8MCArPJtCe47A

Hopefully this link works for you. To elaborate a bit more on what I'd expect from the test strips, when it's actually exposing, I would expect half-stop increments of a 4 second base exposure to give me the following outputs: 4, 1.6, 2.4, 3.3, 4.7, 6. This would give each spot on the test strip and exposure of 4, 5.6, 8, 11.3, 16, 22.

Instead, it looks like it's giving 4, 2, 2, 2, 2, etc.

[glyons]

Yep, this doesn't look quite right at all. I'll need to revert the code back some where in the history and check it again. Thanks for spotting this. Kind of important.

[patrickmorrisphoto]

I've looked around the code. I had no idea how difficult debugging/stepping through code would be for Arduino. I'm also not overly familiar with C/C++ (more of a JavaScript and Python person).

I tried figuring out the calculations, by hand, but I don't think I'm calculating them right. I'm getting weird values from the fstop2TensSeconds and deltaFStop when I calculate them by hand.

I did see a way that I might be able to step through code for debugging in Vs code, so I'll see if I can find some time to do that.

On Tue, Sep 12, 2023, 9:53 AM Gavin Lyons @.***> wrote:

Yep, this doesn't look quite right at all. I'll need to revert the code back some where in the history and check it again. Thanks for spotting this. Kind of important.

— Reply to this email directly, view it on GitHub https://github.com/glyons/Darkroom-Timer/issues/1#issuecomment-1715771839, or unsubscribe https://github.com/notifications/unsubscribe-auth/A4COPUZN2BE7RI62Z6ZGS73X2BSNFANCNFSM6AAAAAA4RWHSTI . You are receiving this because you authored the thread.Message ID: @.***>

[glyons]

I made a javascript version to see how the code works https://codepen.io/Gavin-Lyons/pen/RwEgoBP

I'll updated the javascript with the maths from below, and then update the Repo with the changes

https://www.scantips.com/lights/math.html#3 _Intervals progress in incremental steps. Note these steps are to be multiplied or divided, Not added or subtracted. A disadvantage is that you must know the precise adjacent step, and the precise step value (as opposed to just easily counting up from zero to the appropriate "Stop Number").

f/stop: Full stop = 1.41421356× intervals ( √2) third = 1.122462× intervals (is cube root of √2) half = 1.189207× intervals (is square root of √2)

Example: f/8 - 1/3 EV = 8 × 1.122462 = f/8.979696 Going the other way would divide instead: f/8 + 1/3 EV = 8 / 1.122462 = f/7.12719 (these values are in the chart above) But value 8 is the Stop Number 6 (from index of 1, 1.4, 2, 2.8, 4, 5.6, 8, etc.), so standard way is (√2)(6 + 0.3333333) = f/8.979696_

[patrickmorrisphoto]

I think I got it.
This also may not be the direction you want the code to go in, but it seemed like the only way I could actually get this to increment was by putting the calculation into the for loop. If they were just in the cases, it wasn't incrementing the values at all. I also changed over the increments in the cases to being the fractional values so they could be used in the calculation in the loop.

I also had to create a const for the baseTime so that it would be unaffected by the calculations running against t.

I'm sure professional developers might have a better way to do this; I'm quite clumsy with my coding methods... but.. this code is producing the outputs I would expect:

` let values=[0,0,0,0,0,0]; let stops=[0,0,0,0,0,0]; let selectedArray=[0,0,0,0,0,0]; let exposeValues=[0,0,0,0,0,0]; function stripValueTest(t, mode) {

const baseTime = t var full = [0, 100, 200, 300, 400, 500]; var halves = [0, 50, 100, 150, 200, 250]; var thirds = [0, 33, 66, 100, 133, 166]; var sixths = [0, 16, 33, 50, 66, 83]; var twelveths = [0, 8, 16, 25, 33, 42];

var fraction; var increment = 0; values[0] = t; switch (mode) { case 0: selectedArray = twelveths; fraction = 1/12; break; case 1: selectedArray = sixths; fraction = 1/6; break; case 2: selectedArray = thirds; fraction = 1/3; break; case 3: selectedArray = halves; fraction = 1/2 break; case 4: selectedArray = full; fraction = 1; break; }

for (var n = 0; n <= 5; n++) { values[n] = t; stops[n] = selectedArray[n]; exposeValues[n] = increment; increment = t*(2*(fraction)) - t; t = t(2**(fraction)); } exposeValues[0] = baseTime; return[values, stops, exposeValues]; } `

Given a base exposure of 4s:

For 1/2 stop, this gives the following output: Stops:0,50,100,150,200,250 Expose:4,1.6568542494923806,2.343145750507621,3.313708498984761,4.686291501015241,6.627416997969522 Values:4,5.656854249492381,8.000000000000002,11.313708498984763,16.000000000000004,22.627416997969526

1/3 stop gives: Stops:0,33,66,100,133,166 Expose:4,1.0396841995794928,1.3099200082933056,1.6503957921272017,2.0793683991589855,2.619840016586611 Values:4,5.039684199579493,6.349604207872798,8,10.079368399158986,12.699208415745597

Full stops gives: Stops:0,100,200,300,400,500 Expose:4,4,8,16,32,64 Values:4,8,16,32,64,128

I found the calculations for this method here: https://www.largeformatphotography.info/forum/showthread.php?7894-f-stop-timing-and-partial-stop-calculation&p=37651&viewfull=1#post37651

[patrickmorrisphoto]

Arg, well. I tried to port this over to the Arduino code, and I'm definitely not getting the results I was getting in Javascript. It doesn't seem to be getting the exposure values nor the values. So perhaps this isn't the answer, after all.

[glyons]

Ok, I've updated the Pen https://codepen.io/Gavin-Lyons/pen/RwEgoBP

I think this looks right, I'll port over the code in the today or tomorrow.

Thanks for your help btw!

[patrickmorrisphoto]

You're welcome! I'm definitely happy to help out however I can. I've wanted an f-stop timer for a few years and this looks to be the simplest build I've seen yet.

As I mentioned on a YouTube comment, I may try to add rotary encoders to adjust time up and down (coming from using a gralab 450 for 20+ years, it just makes sense in my mind).

Also, I'm modifying the wiring a bit by using standard AC inputs and outputs that mount to the case, so there's a fuse and on/off switch.

I also may eventually build an LED diffusion head for my enlarger, which would necessitate extra logic in the timer so I can control the LEDs from it. Bonus for that is, if I design it right, I can also adjust contrast by varying greens and blues, and dim if for thin negatives and things like that.

We'll see if I ever make it that far. I think this is going to be fun for a long while.

[patrickmorrisphoto]

I've gotten it working pretty well on the Arduino Uno / TM1638 with the code I've attached here. I had to make a few more changes to the logic to make it work better with C++ (it did NOT like me trying to store the fractions as a variable, so instead, I just store the denominator and pull that in as the "fraction" variable in the calculation itself.

I was going to create a branch and do a PR to pull it in, but it doesn't look like I have permission to. That's okay. Hopefully this code works well for you.

strip_test.txt

[glyons]

@patrickmorrisphoto Thanks again!, I've added the fix to the repo. I'm preparing a follow video with some new feature such as Over the air firmware updating, Enabled/Disable Beeper. Regarding AC inputs and outputs that mount to the case, so there's a fuse and on/off switch. I left that out because each country has it's own regulations.

[glyons]

Fix and Compile Action now implemented on the repo,