Printalyzer - Darkroom enlarging timer & exposure meter

[koraks]

So it really comes down to a simple question of where to draw the dotted line on the block diagram

My suggestion would be to sick with #1. Those who prefer #2 and #3 will figure it out even with minimal/no help from you and just the basic documentation you already provide for your project. Option #1 would pave the way for less advanced users to also get into this technology, and they seem to outnumber the people who would opt for #2 and #3 anyway.

One more thing: https://www.photrio.com/forum/threads/diy-31-megapixel-enlarger.197305
As per this development, it would be useful if the exposure controller could interface with a computer of some sort for exposure sequencing. Basically, it would be very nice if the host computer that displays the digital image on the transmissive LCD could also signal the light source to do its job. This job would depend on the image; for instance, for color, you would have sequential red, blue and green exposures. And for B&W, there's the trick of expanding the dynamic range beyond the 8 bit greyscale depth of the LCD through sequential exposures as well.

I know this complicates the project considerably, but it seems relevant. I think we're going to see these digital LCD's being used a lot more for hybrid enlarging in the future and it would be very neat if there were interoperability with the light source.

 

[albada]

@koraks : I must admit that #1 is easier for most people.

@dkonigs : Here's a discovery that might affect you. A few postings ago, you included Heiland's grade-to-GB table. I just compared my cal-table with his, and although my ER values are close to his, my blue is consistently 1.5 stops weaker than his. Note that my blue has half the power of green. So at full power, it appears that Heiland's blue has 2.5 stops less power than green. Thus, I suspect that he designed his circuitry so that equal power-settings of G and B will mimic tungsten. In general, every DIY LED-head will have a different GB ratio at equal settings. Idea: Let the user enter that GB ratio into your controller. Using the log of that ratio as an offset for B, I think you could use one generic grade-table that would work okay with most papers (from Ilford anyway) and with all DIY LED-heads.

Mark

 

[dkonigs]

@koraks : I must admit that #1 is easier for most people.

Yeah, the trick is finding the right combinations of off-the-shelf parts that can do the job.

And when we're talking about PWM generation, being absolutely precise with the frequency is kinda irrelevant. All that matters is that the clock does not have significant jitter over a relatively short period, because what you really care about is just the ratio between "high" and "low" remaining constant during an exposure. The duration of the exposure itself is externally driven, and being off on responding to that by a few milliseconds is likely no big deal.

@dkonigs : Here's a discovery that might affect you. A few postings ago, you included Heiland's grade-to-GB table. I just compared my cal-table with his, and although my ER values are close to his, my blue is consistently 1.5 stops weaker than his. Note that my blue has half the power of green. So at full power, it appears that Heiland's blue has 2.5 stops less power than green. Thus, I suspect that he designed his circuitry so that equal power-settings of G and B will mimic tungsten. In general, every DIY LED-head will have a different GB ratio at equal settings. Idea: Let the user enter that GB ratio into your controller. Using the log of that ratio as an offset for B, I think you could use one generic grade-table that would work okay with most papers (from Ilford anyway) and with all DIY LED-heads.

The goal with all this is to come up with a set of "sensible defaults" while making things configurable enough to handle all these cases. I could do something like you suggest, or I could simply have a set of max brightness percentages for each channel, or something else.

So along these lines, all of my Heiland controllers have a sticker on the circuit board that reads: "R:80% G:56% B:80%". However, the actual PWM duty cycle it sends out to the LED drivers does not take these numbers into account.
With a max brightness setting on the controller ("-00"), at grade 00 it sends 75% to green and nothing to blue, whereas at grade 5 it sends nothing to green and 75% to blue. (And at every other grade, just multiply 0.75 by the ratios in that table, and that's the duty cycle you see.)

So that label might be simply a rough measurement of how their LEDs actually behave when given the same power, and then they tuned the table from there. But really, without individual LED measurements and/or datasheets, that's just guessing. They also have a series of tiny trim pots on the front of the unit, that you can use to make your own adjustments. I haven't touched them, so I'm just observing out-of-the-box behavior.

 

[albada]

In your UI, you will probably allow the user to set the brightness of R, G, and B. I found that the following are good units to use for this:

brightness = 10.0 + log2(dutyCycle), where dutyCycle is in min..1.0 (min=1/128 for me).​

Let's call these units, "stops below 10". Note that log2 is usually negative.
This is intuitive for users. 10 is max brightness, 9 is half, 8 is quarter, etc. I display them with one decimal point (eg, 8.2).
It's not confusing because higher numbers cause more exposure, which is how time behaves.
It's easy to adjust all channels by the same number of stops.
It's easy to interchange brightness and time.

I started with units of -log2(dutyCycle), but that often confused me because higher numbers caused less exposure, unlike time.
Units of duty-cycle makes it hard to shift GB or RGB by same number of stops, or to interchange with time.
So I found stops-below-10 to work best.

One idea I did not try: Display as duty-cyle (%), but have buttons/knob change them in steps of 1/10 or 1/12 or whatever fraction of a stop you use. Shifting multiple channels or interchanging with time would be possible, but riskier because it's not obvious from the display how many stops a brightness was changed.

Mark

 

[dkonigs]

So, as I'm planning for the next revision of the hardware, I finally decided to go ahead and do some basic temperature testing of the meter probe. It look a bit of work to rig this all up, because the easiest way to do the test involved running the meter probe from a computer (instead of my timer unit) and because I needed to illuminate the sensor via a fiber optic cable coming from a light source outside of the test rig.

In any case, I finally got all the pieces together this evening and collected some data.
I used a similar thermal ramp method as I used to test the densitometer's thermal performance, which involves a freezer and a heated 3D printer filament drying chamber. Its great for ramp testing, but I'd obviously want something fancier if I was trying to build an actual thermal profile. So the data is a bit noisy, given that the hardware doesn't heat evenly and never really reaches a steady state, but its still good for answering some basic questions.

Those questions being:

1. Does temperature affect the sensor's performance?
2. Does temperature affect the sensor's performance enough to actually matter?
3. Is it worth adding a temperature sensor, renting a proper thermal chamber, and building an actual thermal calibration profile?

For these tests, I had the sensor at a fairly high gain setting and the light source at its dimmest. All data is normalized around 25C. (The sensor gave readings that would have been in the ballpark of 0.15 lux if it had picked up the light under my enlarger in a normal meter probe configuration.)

Going all the way from 0-45C, this is what the graph looks like:

The graph is showing differences in reading in stops (log2), and the total range is about 1/4 stop. The jaggyness of the line is most likely due to the inconsistencies in the test method, and not sensor behavior. I'd expect a much smoother line with higher quality steady-state testing.

Someone here mentioned an expected usage temperature range of 17-30C, so I plotted that too:

In this case, we're only talking about a range under 1/10th of a stop.

While it might be a good idea, for the sake of completeness, to test a range of light levels and sensor settings, I think this particular test is likely to end up being close to the worst case scenario.

So I guess now the question becomes... Is it work going through all the trouble to build in temperature compensation to improve accuracy by an amount likely below the typical adjustment increment, for people who build their paper profiles during a summer heat wave and then print in the dead of winter, using a darkroom that's located in an uninsulated shack in their backyard?

Unless I'm missing something, which maybe I am, and you'll all be happy to fill me in.

 

[dkonigs]

I know its been long time since I've updated this thread, but I think its about time that I go ahead and do that...

In video form, I recently posted an update on all my various projects here:


Specific to this project, the hardware design is (hopefully) now final. The main roadblock right now is getting through safety and EMC testing.

I was originally hoping to avoid safety testing by making mains AC switching (turning the enlarger/safelight on and off) someone else's problem, but none of the options for "outsourcing" this meet all my requirements (more detail in the video). So I've been working with a safety testing lab to make sure my own design ticks all the boxes. Fortunately the only changes needed have been labeling/documentation and a few minor nitpicks, but those nitpicks do require some hardware updates.

In any case, my current goal is to get this thing through EMC and safety testing by the end of the year. Once that's done, I'll begin the process of sending out a limited number of pre-production units to help refine the firmware and user experience. I expect this pre-production process to be somewhat lengthy, so I wouldn't be surprised if real production isn't underway until the latter half of next year.

Initially I'm going to start with more technical test users, and then gradually expand the group from there. But since the labor to actually build these pre-production units is significant, the total number of units at this stage will be quite limited.

 

[kuhyraco]

I wish you much success. I had high hopes for another project years ago, but it didn't work out (MAYA - The Only Darkroom Timer You'll Ever Need Never Get)

I just want to ask, am I assuming correctly that to fully utilize your timer, you need to work with white light and control the contrast with filters, whether classic Ilford or a color head?
Today it is popular to make heads with blue and green (or red) LEDs, but that can't be measured sensibly, right?

 

[dkonigs]

I wish you much success. I had high hopes for another project years ago, but it didn't work out (MAYA - The Only Darkroom Timer You'll Ever Need Never Get)

Still not sure what's going on with the Maya project. It had some aspects I liked, some I didn't, and some "yadda yadda" handwaving on the things that are actually development concerns of mine.

I just want to ask, am I assuming correctly that to fully utilize your timer, you need to work with white light and control the contrast with filters, whether classic Ilford or a color head?
Today it is popular to make heads with blue and green (or red) LEDs, but that can't be measured sensibly, right?

Sort of, but not exactly.
The idea is that it uses white light to do all of the metering, but you can use anything you like (filters, LED ratios, etc) for the actual exposure. If your LED setup doesn't have a "white" source, then RGB all on together (whatever mode typically used for "focusing") is likely close enough.

The paper profiles are basically establishing the relationship between a "white" meter reading and a "colored/filtered" exposure for the same film/time.

There's really no good way around an approach like this, for two reasons:

1. Every light source, filter configuration, and paper has a different spectral output or sensitivity. Meanwhile all the standards are written in terms of lux-seconds, and you have to standardize on something.
2. The white light is usually brighter, and thus easier to measure. With an enlarger lens stopped down you're often already scrambling for photons to sense.

(Okay, you could do better with a lot of fancy spectroscopy, but that quickly gets far too expensive and complicated.)

 

[kuhyraco]

Still not sure what's going on with the Maya project. It had some aspects I liked, some I didn't, and some "yadda yadda" handwaving on the things that are actually development concerns of mine.

Yeah, I'd be interested in what happened too.

Sort of, but not exactly.
The idea is that it uses white light to do all of the metering, but you can use anything you like (filters, LED ratios, etc) for the actual exposure. If your LED setup doesn't have a "white" source, then RGB all on together (whatever mode typically used for "focusing") is likely close enough.

The paper profiles are basically establishing the relationship between a "white" meter reading and a "colored/filtered" exposure for the same film/time.

There's really no good way around an approach like this, for two reasons:

1. Every light source, filter configuration, and paper has a different spectral output or sensitivity. Meanwhile all the standards are written in terms of lux-seconds, and you have to standardize on something.
2. The white light is usually brighter, and thus easier to measure. With an enlarger lens stopped down you're often already scrambling for photons to sense.

(Okay, you could do better with a lot of fancy spectroscopy, but that quickly gets far too expensive and complicated.)

I wrote about light measurement, but the problem lies elsewhere. I have a DIY solution that controls the green and blue LEDs and of course the exposure. I can imagine adding a red LEDs to head for metering and easier focusing, but I still wouldn't be able to use your timer to control exposure.

I don't actually know if it would be possible to set the green/blue LED ratio in advance and then "fire" it with your timer. Just like the Ilford Multigrade head or Heiland Splitgrade, they have their own controller.

 

[dkonigs]

I wrote about light measurement, but the problem lies elsewhere. I have a DIY solution that controls the green and blue LEDs and of course the exposure. I can imagine adding a red LEDs to head for metering and easier focusing, but I still wouldn't be able to use your timer to control exposure.

I don't actually know if it would be possible to set the green/blue LED ratio in advance and then "fire" it with your timer. Just like the Ilford Multigrade head or Heiland Splitgrade, they have their own controller.

The big problem with LED heads is that they're all bespoke and/or DIY solutions. But this is something I have thought about, and do have a solution for. Its just not something that can always be plug-and-play.

For the simpler approach, if the LED driver is designed to be triggered by sensing voltage on an AC power plug, you can use it just like any ordinary enlarger. One of the Heiland control box options works this way, as do many traditional voltage-stabilized enlargers. (This is why the timer rarely needs to switch a lot of current, because the bigger enlargers just use the timer's output as a trigger and not as an actual power source.)

For a more complete solution, my timer has another way of controlling enlargers. It has a DMX512-compatible control interface, which is a standard lighting control protocol for which you can either get existing hardware or easily build your own.

For DIY LED heads, you can actually buy an off-the-shelf LED driver that speaks DMX512, and my timer can directly control the R/G/B/W channels. (Obviously configurable, and something I'll be improving with software updates over time.)

For off-the-shelf LED heads, you can make an adapter box to replace the bespoke controller they ship with. I've already done a proof-of-concept for this with the Intrepid head, and the Heiland head shouldn't be too difficult either (I know a lot about how both work). My plan is to either publish reference designs, or make hardware kits, for doing this. (The likely "stack" will be some sort of off-the-shelf Arduino, some sort of off-the-shelf Arduino DMX shield, and a board with the head-specific interfaces.)

I put a little demo of how this works in this old project update video:


I'll definitely need to make some newer example videos once things settle down and everything is back on track.

 

[calebarchie]

Sorry if I missed this earlier, but is this project open? Or would you consider selling kits/boards?

Edit: just found the GitHub page

 

[dkonigs]

Sorry if I missed this earlier, but is this project open? Or would you consider selling kits/boards?

Edit: just found the GitHub page

Depends on what you mean by open.
All of the designs and code for the device itself are open source.
There's a long tail of related materials that may or may not get published (documentation sources, internal utilities, assembly jigs, artwork, etc). That's mostly something where I hope to put out as much as possible, but getting it all nicely collected in an easy-to-publish way is easy to fall behind on.

As far as the device itself, I'm not planning on selling kits or boards. I am planning on selling complete devices.
I might take the kit/board route for adapters to connect the DMX port to various LED enlargers, however.

 

[kuhyraco]

The big problem with LED heads is that they're all bespoke and/or DIY solutions. But this is something I have thought about, and do have a solution for. Its just not something that can always be plug-and-play.

For the simpler approach, if the LED driver is designed to be triggered by sensing voltage on an AC power plug, you can use it just like any ordinary enlarger. One of the Heiland control box options works this way, as do many traditional voltage-stabilized enlargers. (This is why the timer rarely needs to switch a lot of current, because the bigger enlargers just use the timer's output as a trigger and not as an actual power source.)

For a more complete solution, my timer has another way of controlling enlargers. It has a DMX512-compatible control interface, which is a standard lighting control protocol for which you can either get existing hardware or easily build your own.

For DIY LED heads, you can actually buy an off-the-shelf LED driver that speaks DMX512, and my timer can directly control the R/G/B/W channels. (Obviously configurable, and something I'll be improving with software updates over time.)

For off-the-shelf LED heads, you can make an adapter box to replace the bespoke controller they ship with. I've already done a proof-of-concept for this with the Intrepid head, and the Heiland head shouldn't be too difficult either (I know a lot about how both work). My plan is to either publish reference designs, or make hardware kits, for doing this. (The likely "stack" will be some sort of off-the-shelf Arduino, some sort of off-the-shelf Arduino DMX shield, and a board with the head-specific interfaces.)

I put a little demo of how this works in this old project update video:


I'll definitely need to make some newer example videos once things settle down and everything is back on track.

It looks like you've thought of everything, this is a very interesting feature.

I wanted to order two new timers early next year, it looks like I'll have to wait and see how your project develops. It's still too early to give a rough estimate of the price, right?

 

[dkonigs]

It looks like you've thought of everything, this is a very interesting feature.

I wanted to order two new timers early next year, it looks like I'll have to wait and see how your project develops. It's still too early to give a rough estimate of the price, right?

Yeah. My goal is to have pricing in the same ballpark as other similar products, but there are so many variables its hard to say. Fortunately I don't need the same sort of profit margin as Heiland. Unfortunately, I'm not just continuing to sell things mostly designed and built during a particularly productive period around 2012.

Right now I just need to get the hardware through safety and EMC testing, after which I'm going to start seeding a few hand-build units to test users as the firmware is ironed out and I start working on production. A lot of the delays here depend more on other people than my own work.

 

[Faraz]

I've been building v2 of my own arduino 2560 mega embed based timer with a bespoke LED head, I've had a number of people askling if I plan to productize - But the complexity of the whole AC certification, and being nowhere as capable or electronically literate as you, I don't even want to touch it! I wish you the best with the testing and cert.

It may have failed, but the Maya project did at least provide some inspiration - specially on the whole programmability of it which I loosely based mine on.

There's some gems of info in this thread I'd wish I read this thread earlier, specially about DMX512, too late now with pcb printed and custom cables made up etc...ah well v3

 

[dkonigs]

I've been building v2 of my own arduino 2560 mega embed based timer with a bespoke LED head, I've had a number of people askling if I plan to productize - But the complexity of the whole AC certification, and being nowhere as capable or electronically literate as you, I don't even want to touch it! I wish you the best with the testing and cert.

Yeah, and its also why I ended up putting my own project on the back burner many times. I've desperately wanted to "outsource" this problem to someone else's hardware, and have chased every opportunity to do that which came up. But nearly all of the solutions I've found fail my requirements, such as being compact, affordable, internationally-compatible, easy to integrate, and actually having certifications themselves.

(The final rabbit hole was exploring the line of products the latest version of the Filmomat timer uses, and some similar devices, only to discover they're literally just "relay in a box" with no certifications.)

Ultimately my solution has been to work with a local safety testing lab to make sure I meet all the relevant criteria for proper safety certification, and have a report to prove it. (Even if the actual NRTL "marking" isn't practical to maintain due to lack of a regularly-inspectable factory.)

Fortunately I was already pretty close. The only changes I've actually needed were some nitpicky things about how ground wires are handled and a bunch of labeling/documentation related items.

It may have failed, but the Maya project did at least provide some inspiration - specially on the whole programmability of it which I loosely based mine on.

Yeah, the project did have a lot of interesting ideas an an overall nice design. I think my only real "gripe" was that it was trying to be a "do everything" timer and not a dedicated enlarger timer.

There's some gems of info in this thread I'd wish I read this thread earlier, specially about DMX512, too late now with pcb printed and custom cables made up etc...ah well v3

DMX512 was an interesting discovery. The need to interface with all sorts of modern DIY (and non-DIY) LED heads means I need an interface other than a simply AC power outlet. But if you ask people what they want, they'll just vaguely mention "PWM" or "GPIO" without realizing that this isn't actually a "standard" and has a lot of implementation details which will vary from person to person. Meanwhile, DMX512 is this broadly implemented standard with a lot of existing hardware out there. So you can actually simply buy off-the-shelf products which can be controlled with it.

Of course you can also implement it yourself without too much fuss. All its really doing is regularly spewing a stream of 512 8-bit numbers, so you listen to the right ones and make your controller react accordingly. (And you can combine adjacent channels for 16-bit control, which some DMX LED drivers support, which is actually preferable for this application.)

 

[Nicholas Lindan]

The easiest way through the safety swamp is to use a wall wart power supply and bluetooth controlled AC outlets for the enlarger and safelight. UL doesn't concern itself with circuits that run on 5V. I guess UL has never seen the result of short-circuiting a 5V/300A rail.

 

[dkonigs]

The easiest way through the safety swamp is to use a wall wart power supply and bluetooth controlled AC outlets for the enlarger and safelight.

The problem with those is that timing may not be consistent, and its a complete mess of different products from different vendors to cover an international userbase. Also, in many cases these things are not actually bluetooth controlled. They use bluetooth for setup, but are then controlled over WiFi.

So like many options, it might work for a single-user kludge, but isn't really a good universal solution for an end product.

UL doesn't concern itself with circuits that run on 5V. I guess UL has never seen the result of short-circuiting a 5V/300A rail.

Actually, it kinda does
When talking with my rep from the safety testing lab, he's mentioned that the limit for "UL doesn't care" is 15VA. Of course when trying to search the source for these numbers, you see a lot of different charts across a lot of different standards. However, 5V/300A would easily exceed the limits in all of them.

 

[kuhyraco]

I have one more question about LEDs.....is it necessary to have a separate white LEDs in the light source for measurement, or can "white" light from an RGB LEDs be measured?

 

[dkonigs]

I have one more question about LEDs.....is it necessary to have a separate white LEDs in the light source for measurement, or can "white" light from an RGB LEDs be measured?

That one is hard to answer without specific testing, but honestly this is true of all LED configurations and use cases.

"White" from an RGB source should be sufficient but it likely depends on the specific source. Likewise, "white" from many white LEDs is actually has similar concerns, as many white LEDs emit nowhere near as clean as a normal tungsten lamp.
(The spectrum of "white" LEDs often has a large blue spike, then a gentle curve across the spectral range. Avoiding this requires tracking down better high CRI LEDs from places like Seoul Semi and YujiLeds.)

The actual sensor in the meter probe is tuned to the "Photopic" spectrum, which basically means its measuring lux. In practice, that's a heavily green biased measurement. (For reference, all the ISO standards about B&W photographic paper response curves and density measurement are actually written in terms of this spectrum, to some extent.)

 

[dkonigs]

So a little update...
The project itself is still temporarily on hold, pending an updated enclosure from my enclosure vendor. This is taking way longer than it should, but its still an active work-in progress. Once I get that updated enclosure, I'll resume the safety testing/reporting process and finally get EMC testing scheduled. Those things are the final hurdles I need to pass before I can start building and distributing pre-release hardware.

In the mean time, I've circled back to seriously thinking about the problem of "enlarger adapters." Basically little bits of hardware that will connect to the DMX512-compatible expansion port and allow people to use "non-traditional" enlargers to the Printalyzer Timer.

What is a "non-traditional enlarger" in this context? Well, basically any enlarger that's controlled by some means other than toggling power to an AC outlet.

Now as already discussed above, we have off-the-shelf LED drivers and end-user DIY hardware as options in the mix. And for many cases, this is fine. But there are also cases where I could actually provide something for people. Specifically, I'm thinking of cases like certain off-the-shelf enlargers which have non-traditional control interfaces.

Right now, I've been investigating how to control the following products:

• Intrepid Enlarger Kit (LED head)
• Heiland LED Cold Light Source (LED head)
• Ilford Multigrade 500 Enlarger Head System (blue/green halogen head)

(Is this a good starting list? Are there others worth investigating?)

Now my goal is to produce something to make connecting these enlargers as easy as possible, but without making a "real product" out of the adapter. (Since any adapter is going to be a bespoke low-volume thing.) Think of it like a DIY kit, except that the majority of the hardware in this kit is something you'd buy separately and/or from somewhere else. (e.g. like a lot of things built out of parts from Adafruit or Sparkfun).

So my current thinking is that the "adapter" will consist of the following components:

• Arduino Uno base controller (most likely UNO R3 or UNO R4 Minima)
• Conceptinetics DMX Shield (available from CQRobot, DFRobot, Keyestudio, AliExpress, etc.)
• Custom shield board (something I'll provide, will need to be enlarger-specific and may come with cabling)
• Custom firmware to run the thing (also something I'll provide)

Ideally this will all be powered by the same power supply as the enlarger itself. That should be possible in most cases, because this "stack" will connect to the enlarger in the same way as its vendor-supplied control panel (which also needs power).

To house all of this, I might provide a 3D printed enclosure, and/or a design for one, but any random black box will probably be fine. (Though how sealed this box needs to be will depend on whether you're willing to desolder the LEDs from the Arduino board.)

The actual complexity of this "custom shield board" will vary quite a bit depending on the enlarger. In some cases it could be little more than a fancy wiring harness, and in others it might have some actual circuitry.

Another thing I'm thinking about including on this custom board is a dedicated DMX receiver IC. I recently discovered the IS3710 (one is on-order to test), and its quite tempting as a way to dramatically simplify the firmware for this project. Its not that an Arduino can't handle DMX by itself, its more that all of the Arduino DMX libraries are old and creaky (and don't support the R4), and the Arduino platform itself has some limitatings that make doing it on-board kinda annoying.