Printalyzer - Darkroom enlarging timer & exposure meter

[dkonigs]

Thank you - I have the RH Designs, and the crosshairs are like those; I also have Nicholas' meter which has thicker lines. The DA meter is easier to see.
(I should mention that it's nigh impossible to see the meter hole on the RH designs when exposing for dark areas - I have the latest version)
Final edit - I also have your densitometer, and even with the light on, I still can't measure 135 negs as I'd like; taking multiple measurements to find darkest areas, perhaps it's me. FWIW, I can't be any more satisfied with it

The actual design of the overlay is TBD, so I can change the colors and/or make the lines thicker.

Making the lines backlit is an idea that never occurred to me, and might be easier said than done, and I'm not sure how much it would actually help. Of course going with a pointed shape for the probe itself probably does help here. The only downside is that it pretty much requires the probe to be a custom piece of plastic, unlike the repurposed off-the-shelf enclosure RH uses. Thankfully 3D printing helps out there.

 

[dkonigs]

So speaking of all these EMI concerns... Be assured that the sort of testing I plan to do is not limited to quick-and-dirty fiddling with bad wires and radios. Because the intent is an actual product, I need to pass the real EMC/EMI tests in a proper lab. I have a spectrum analyzer and various related pieces of equipment for preliminary testing here, and will be using them. Emissions is probably the larger concern upfront, but there will also be some level of immunity testing.

Also, one of the great things about picking DMX512 as the expansion protocol, is that you can simply buy off-the-shelf hardware to work with it. You don't need to DIY your own LED drivers, because you can simply go online and buy them. Of course its still possible off-the-shelf options won't meet your needs, or that there are EMI issues on the output side, but simply having this option can save a lot of work.

 

[dkonigs]

So a few days ago the latest prototype enclosure arrived, I installed everything, and took a few quick pictures!

(Sorry if they're not tack-sharp. When I'm finally ready to take real product photos for the website, I'll obviously put in the effort to do this under well-lit pristine conditions.)

 

[koraks]

Looks really nice and professional - conveniently compact, also.

 

[calebarchie]

Looks very good! Any updates on the EMI/RF compliance? Also, can you provide the supplier/part number for those keycaps?

Cheers

EDIT: They appear to be for MARQUARDT 6xxx series switches

 

[Joel_L]

That looks great!

 

[dkonigs]

Looks very good! Any updates on the EMI/RF compliance? Also, can you provide the supplier/part number for those keycaps?

EMC compliance has been an interesting situation as of late. Right now my concerns have more to do with power supplies and emissions, rather than the signal immunity case discussed at length above. So most of my testing has involved measuring conducted emissions on the power cables, rather than running the meter probe next to someone's terrible non-compliant buck converter.

So the AC/DC converter brick I originally decided to use in the current prototype (Mean Well IRM-10-12), despite claiming to have an EMI filter and claiming to meet all the standards, is incredibly noisy. Like seriously, so bad I want to call shenanigans on the manufacturer.

(My first prototype, from a few years ago, used a CUI PSK-6B-S12. Its not perfect, but it is a lot better. Though it doesn't have the greatest availability anymore.)

Selecting the AC/DC converter brick for the device is both an important decision, and a difficult one. This is a somewhat annoying product category, because there aren't that many choices, most of them tend to have mediocre availability, they can easily get expensive, and they all make the same lofty claims about safety and EMI standards compliance.

In any case, about a week ago I discovered a relatively new entrant to the product category. The Recom RAC10E-12SK/277. Its the same specs as the MW unit, the same size, same footprint, and same price. In other words, a very easy drop-in replacement that I can test on the exact same hardware. I tested it, and its a night-and-day difference.

(This is just a bench test of the power board by itself. The only noise in the bottom photo is an artifact of the wires in my test setup picking up local radio stations.)

Sometime in the next few days, I plan to do a 3-way shootout between complete prototypes to get a better picture of overall performance. First prototype /w CUI, current prototype /w Mean Well, and current prototype /w Recom. Regardless, I think Recom is the path forward here.

EDIT: They appear to be for MARQUARDT 6xxx series switches

Yeah, the top buttons are from the Marquardt 6425.xxxx series. 3 variants, actually. One normal design, one with an embedded LED, and one that's slightly narrow so this elongated guide piece can fit on top to allow for the longer expose/focus buttons.
The associated keycaps are the "825.000.xxx", "828.000.xxx", "844.000.xxx", and "827.000.xxx" series. These all come in a few colors, though I'm prefering the lighter grey option. (used black in an early prototype, and it looked nice in pictures, but I think grey is easier to see in practice.)

I'm also using Maraquardt switches for both power and "blackout". Went through a variety of options for the blackout switch, ultimately settling on the "1911.xxxx" series. Its overkill in terms of size/rating for that, but is thin and has a really satisfying "clunk" feeling that works well for the application.


In any case, most of my other work has been around simply getting up and running with some of the new hardware. I've been slowly writing driver code for the new light sensor and figuring out its behavior, and I've also been working on getting that XLR jack on the back to send out valid DMX512 frames and thus control lights. This is all generally low-level work, as I haven't even started the higher level bits of actually working it into the operation of the overall unit.

Though I haven't had all that much time to work on things these past few weeks. Recently went on a family vacation, then had some break time at home recovering, then everyone got sick... in a staggered sequence... and maybe in another week or two I'll finally be able to start working at 100% again. There's a lot I can do in "a little bit here, a little bit there" fashion, but that mode of operation does have its limits.

 

[dkonigs]

I figure its about time for another update, to show where things have been going and some of what I've been working on.
One thing I've been putting a lot of effort into recently, is building out all of the stuff around DMX control for LED enlargers.

One nice thing about this, is you can buy cheap DMX RGBW fixtures off Amazon to use as test devices. These little things are great for that, even if that's obviously their only real use:

Of course you can also buy standalone LED driver bricks with nice little displays, which are a great way to quickly see exactly what control signals are being sent out:

(This one supports 8-bit with linear or gamma curves, or 16-bit, and of course I want to test both.)

What's really nice about using a standard here, is that you really don't need to DIY your own LED driver if you're making an LED head. You just need to worry about the head itself. (Assuming you can find a driver that meets all of your needs, but there are plenty to choose from.)

Where the real complexity comes in, of course, has been building out all of the configuration screens and settings for this:

(This is just a few bits of it. There's actually quite a bit more.)

Overall, the goal is to support using Relay controlled outlets or DMX control signals for both the enlarger and the safelights. (its either/or for the enlarger, but and/or for the safelights)
And yes, I'm supporting 8-bit and 16-bit mode for the DMX signals.
I'm also trying to support every combination of use cases here, as I have no idea what sort of rigs people will have. That means the enlarger can be White, RGB, or RGB+W. Contrast control can be via traditional filters or a profile of green+blue combinations. And there's even support for a "safe" red-light mode when between test strip patches or dodge/burn steps.

Finally, having all this also means that I need to support separate main screen modes for "B&W Printing" and "Color Printing". That way in the color printing mode, the contrast grade stuff disappears and you have direct control over the RGB values. I'm tempted to consider a way to switch that over to CMY values to mimic a dichroic enlarger, but there's still a lot of research to figure out how to actually map that sanely. (Going to be looking closely at how other LED enlargers do it, but its not clear-cut.)

Oh, and one more thing... I did a little bit of kludgy tinkering with an Arduino and a DMX shield, and managed to get my timer to control an Intrepid LED enlarger head

(The basic Arduino really isn't the best tool for the interface job, and the various stock libraries aren't really that great for this use case out-of-the-box either, but its still a great demo. While I'd absolutely design an interface widget differently if I was building it myself, there's real value in people being able to do this with off-the-shelf bits and bobs. So I probably will figure out how to modify some of the libraries I'm using to get this working better.)

 

[albada]

You mentioned a "profile of green+blue combinations", which I assume is a LUT indexed by grade that yields the PWMs for G and B.
A LED head provides an important advantage over tungsten: One can control brightness by changing G,B in tandem. So I set time and f-stop to what I want, and set overall exposure via the brightness "knob".
Your UI lets the user change the time and contrast "knobs" to position meter-readings correctly on the grayscale.
I encourage you to add a "brightness" knob as well. I find it a useful feature.

One way to incorporate brightness would be to add an interchange feature that, using your rotary encoder, changes both time and brightness in tandem, keeping exposure unchanged (assuming no reciprocity failure). Another way would be to add a time/brightness mode, so that the buttons that ordinarily set time will set brightness instead. The range of brightness depends on contrast, with a smaller range at low contrast due to the large G/B ratio. So one must be careful to integrate brightness into the UI gracefully.

Mark

 

[albada]

No. I'm using a 6-pin Mini-DIN cable for the meter for the sake of convenience, as it lets me re-use the massive existing stock of PS/2 style cables and connectors out there. However, the protocol itself is quite different.

Its based on I2C, with extra pins for the sensor interrupt and the push button. The design goal is basically to avoid needing to put a microcontroller inside the meter probe itself, while also being able to support different meter probe variants with different sensors. So beyond various bits of support circuitry, there are basically 3 functional components inside the meter probe itself:

1. The light sensor
2. A small memory chip that's programmed with the meter probe ID and any calibration values for the sensor
3. The push button

Of course I did use a pin-out similar to PS/2, so it probably wouldn't harm a computer if you did plug it in. And it wouldn't harm the Printalyzer Timer if you plugged a keyboard or mouse into the port. But it wouldn't actually do anything useful.

You might want to add an I2C temperature-sensor to the probe, allowing you to calibrate-out temperature-based shift in the lux-sensor, in case it's significant.
Summer/winter temps can be quite different, and if the user leaves his hand on the probe, it might become considerably warmer.

Mark

 

[dkonigs]

You might want to add an I2C temperature-sensor to the probe, allowing you to calibrate-out temperature-based shift in the lux-sensor, in case it's significant.
Summer/winter temps can be quite different, and if the user leaves his hand on the probe, it might become considerably warmer.

Mark

The way the probe is constructed, the user's hand is unlikely to get close enough (or conduct enough heat) to the actual sensor element to make a difference. And if this sensor performs anything like the sensor I'm using in my densitometer, the amount of temperature swing needed to have a noticable impact on readings would far exceed what a human operator would be willing to tolerate. Its still probably worth testing, though, even if to see where the limits are.

 

[albada]

The way the probe is constructed, the user's hand is unlikely to get close enough (or conduct enough heat) to the actual sensor element to make a difference. And if this sensor performs anything like the sensor I'm using in my densitometer, the amount of temperature swing needed to have a noticable impact on readings would far exceed what a human operator would be willing to tolerate. Its still probably worth testing, though, even if to see where the limits are.

The datasheet for the TSL2585 says, "While the device is operational across the temperature range, functionality will vary with temperature." Its lack of temperature-data disturbs me.
I've noticed that the Darkroom Automation meter appears to vary some with temperature, but I need to test that more to confirm that it's not due to my LED drivers.
So I think it's worth testing this sensor, especially at low light-levels which are affected by noise most, at the winter/summer temperatures of 17 and 30 degrees.

Mark

 

[dkonigs]

So I've probably now spent way too much time digging into the interfaces and control schemes of certain existing LED-based enlarger heads, and have learned a lot about how they work and how their control boxes operate them. I might as well share a brief version of my findings, and how it pertains to being able to run them from my timer:

Intrepid:

• Head is constructed out of an array of addressable RGBW LEDs (a.k.a. "Neopixels")
• The connectors on their cable are most commonly found on cables sold as an "E-Bike signal connector" cable.
• Runs off of 5V power, with a 5V digital control signal (3 pins)
• Control scheme based on 8-bits per channel, with a linear relationship between user input and device output
• Color operation uses subtractive (C-M-Y) settings that appear to be based on something, but I'm not sure what.

Heiland:

• Head is constructed out of an array of separate Red, Green, and Blue LEDs with on-board driver transistors
• The connectors on their cable are somewhat unusual and expensive, but relatively easy to find on Digi-Key if you know what to look for.
• Runs off 24V power, with three 12V PWM signals to control channel brightness (5 pins used)
• Control scheme based on 16-bits per channel, with inputs exposed in a more user-friendly fashion that hides the raw values
• B&W operation:
  • Contrast is based on a look-up table that uses values on a scale of 0-200
  • Brightness is based on a value from 0 to -40, on a logarithmic scale (in units of 1/10th of a stop)
  • Max brightness appears to actually be only a 75% duty cycle.
• Color operation:
  • Uses an additive (R-G-B) input scheme, on a scale of 0-400.
  • Each downward tick of the input value reduces brightness on a logarithmic scale in units of approximately 1/37th of a stop.
  • Max brightness actually is around 100%.

This ultimately leads to 3 different approaches to building adapters to connect LED enlargers to my timer:

• Intrepid-style adapter
  • Can be built out of a bog-standard Arduino UNO R3, an off-the-shelf DMX512 shield, a barrel jack for the power supply, and some quick and dirty wiring. (as shown in an earlier post)
  • Firmware will need some customization of the existing Arduino libraries for DMX and/or Neopixel operation, to resolve some timing issues. But it should be do-able.
• Heiland-style adapter
  • Cannot be built entirely out of off-the-shelf bits, but isn't that complicated otherwise
    • Needs a microcontroller than can support at least 3 channels of 16-bit PWM at a decent frequency
    • Needs the parts to interface to a DMX512 link
    • Needs some custom circuitry that can provide a 12V source off the 24V supply, and switch that using a PWM signal from the microcontroller.
    • Needs a place to put the barrel jack for the power supply, and the rather unusual connector for the enlarger plug.
  • Could possibly be built out of an Arduino UNO R4 Minima, an off-the-shelf DMX512 shield, and a custom shield board to handle the rest of it. Would still probably need some custom code, but that can be provided as an example.
• Simple adapter for everyone else's DIY projects
  • Buy a DMX512 LED driver brick, preferably with 16-bit support, from the usual places (e.g. LT-820-5A)
  • Buy some XLR connectors (or a breakout board that already contains them)
  • Wire this all together with your power supply of choice and LED array of choice
  • Finished!

This makes me rethink my whole approach to 8-bit vs 16-bit control. Initially, I thought to do both of them the same, except 16-bit would get a much larger range of values (e.g. 0-255 vs 0-65535). This is certainly simpler, especially if you want to flip back and forth. But I now realize that the real advantage of 16-bit is not more granularity on the user side. Rather, its a decoupling of user input values from raw PWM values without rounding errors breaking the whole thing.
In other words, if you only have 8-bit control, you pretty much have to use the approach Intrepid is using. But if you have 16-bit control, then it makes more sense to use Heiland's approach.

This might end up leading to a different set of features and control inputs for both. For example, I wouldn't want to do any sort of logarithmic brightness control on 8-bit. Perhaps not even brightness control at all. And I certainly can't use a contrast LUT with a clean 0-200 scale for 8-bit either. But it all fits in quite nicely with 16-bit.

Finally, there's the whole question of "R-G-B" vs "C-M-Y" for color, and the scaling of input values. I'm not sure which approach is better, so it might make sense to simply offer choice. But one thing that I think is worth doing, is making it operate in the same "units" as dichroic adjustments (and Kodak viewing filters) to make the user experience better.

 

[koraks]

For example, I wouldn't want to do any sort of logarithmic brightness control on 8-bit. Perhaps not even brightness control at all. And I certainly can't use a contrast LUT with a clean 0-200 scale for 8-bit either. But it all fits in quite nicely with 16-bit.

That was indeed also my conclusion - that at least 12 bits of PWM resolution is required to do color work (in a meaningful way).

But one thing that I think is worth doing, is making it operate in the same "units" as dichroic adjustments (and Kodak viewing filters) to make the user experience better.

That's what I did initially in my enlarger. In the end, I let it go, because I found the supposed 'compatibility' with a dichroic setup proved to be not very relevant in practice anyway. It's a nice touch, and I can see where Heiland came from when they implemented the way they did. It's in fact interesting/funny to read that they reached a similar solution to what I did, previously. In the end, I just programmed my LED controller to perform a third power polynomal on the user input value and make the parameters adjustable through a setup screen. I then just started working with the thing and ended up adjusting the parameters to taste and requirements when I had gained some experience in using it.

Not sure how useful this is to you - probably barely, at all. Sorry about that.

 

[ic-racer]

Yes, 30 cc filtration = log 0.3 = one stop etc.

 

[mshchem]

I would HIGHLY recommend forgetting about color. I have 3 or 4 dichro heads I can use for color, something I still do, but it's a couple times a year.
If you do choose to push for color LED it's imperative that it is linked to CC and CP filter values.

It is a ticking time bomb as to when Fujifilm stops selling cut sheets of crystal archive paper. When this happens, rolls, often sold 2 or more in a case pkg will be it. For potential customers of a timer for an enlarger for printing color negatives?? anyone's guess??

I have Beseler and Zone VI enlargers, all working. HOWEVER when the color head on the Beseler dies I'm left with a condenser lamphouse. When the Zone VI VC cold light heads go ????? There's a lot of Beseler and Omega enlargers that would benefit from a not to complicated source and controller that is "the cat's meow" for VC split grade printing.

The Ilford Multigrade heads and controller are about as cool as it gets. I watch Darkroom Dave with his 4x5 DeVere and his Ilford head. This is what I dream of!

If you insist on messing with color, make a Video Color Analyzer, LED tablet like iPad, a little box that you could slide in the negative and twirl knobs until it showed the proper filtration. Kodak sold an outfit like this in the 70's, it was about $35k US.

 

[koraks]

it's imperative that it is linked to CC and CP filter values.

Not really.

When this happens, rolls, often sold 2 or more in a case pkg will be it

Rolls are fine. I and many others use this approach and its cost effective and quite convenient.

It doesn't have to be all that complicated.

 

[mshchem]

Not really.



Rolls are fine. I and many others use this approach and its cost effective and quite convenient.

It doesn't have to be all that complicated.

Well, we can disagree on this. I've been printing color since CP 5 and Ektacolor Professional fiber base color paper, man that was the greatest, I would not want a setup where filtration steps were a guess. And I'm not going to shell out 300 or 400 dollars to buy 11 rolls of consumer grade Fuji paper. This is my feeling, you obviously don't feel the same.

 

[koraks]

Yeah, disagreement is fine, and I think it stems mostly from different experiences and different printing habits. I don't need to stock 11 different papers since I'm happy with one or two surface finishes. So that means I need only one or two rolls "on tap". And having printed for a few years with LED light sources now, I've learned that the tracking with the CC logic of dichroic heads just doesn't have much practical relevance. You get used to whatever other system you can dream up within a few sheets.

 

[mshchem]

I would love to have access to different papers. Just not available in the US without buying directly from Fuji with a commercial account. Crystal Archive is great paper, what I've been using, glossy, for years, since Kodak stopped with cut sheets.

I love printing, I've got a fully equipped lab. Maybe I will buy a roll of professional Fuji paper, I may need help sourcing it from the EU

 

[mshchem]

I just remembered I have a roll easel. Up to 11 inch, every mask they made. This is a great project!

OK forget what I said.

I want LED colorheads for 8x10 and 5x7 Zone VI and 4x5 Beselers with F stop controls!!

 

[albada]

1. For B&W, 8-bit PWM is poor, even without brightness control. Here's why:
At the lowest contrast with Ilford and Foma papers, one still needs a little blue, because without it the curve has a shoulder that's too long. A little blue lets one reach D-Max with a reasonable exposure. In my calibrations, that "little blue" is around six stops below green (assuming equal power in G and B LED-chains).
With 8-bit, if green=255 (i.e., at max), then blue=4. That is poor resolution in blue. I'd say one needs at least 10 bits to print low contrasts accurately enough.
Adding a brightness control of say 4 stops adds 4 bits. Now we're at 14 bits.

Hence my suggestion: Don't even support 8-bit PWM.

2. Another consideration regarding brightness and contrast:
When changing contrast below grade 4, Ilford's filters keep light tones constant.
To do that with LEDs, a contrast-change will need a corresponding brightness-change to keep the highlight probe-measurement unchanged (stationary on the display). If you simply keep G or B at its max, then a contrast-change will cause all measured points to move, which will irritate the user. I suggest keeping the rightmost point (highlight) stationary, as doing so fits well with the popular approach of setting exposure for highlights and contrast for shadows.

3. A note for everyone: The Arduino Uno (ATmega328p) has only two 16-bit PWMs; the rest are 8-bit. That makes it unsuitable for color. For color, I suggest using a higher-end Arduino, or a PIC18 (works well for me), or a 32-bit MCU.

Mark

EDIT: 8-bit is fine if the units are scaleFactor*log2(pwm), instead of linear PWM. Darkroom Automation, Heiland, and I use units of 1/10 stop, so our max round-off error is 1/20 stop.

 

[dkonigs]

1. For B&W, 8-bit PWM is poor, even without brightness control. Here's why:
At the lowest contrast with Ilford and Foma papers, one still needs a little blue, because without it the curve has a shoulder that's too long. A little blue lets one reach D-Max with a reasonable exposure. In my calibrations, that "little blue" is around six stops below green (assuming equal power in G and B LED-chains).
With 8-bit, if green=255 (i.e., at max), then blue=4. That is poor resolution in blue. I'd say one needs at least 10 bits to print low contrasts accurately enough.
Adding a brightness control of say 4 stops adds 4 bits. Now we're at 14 bits.

Hence my suggestion: Don't even support 8-bit PWM.

I still want to support everything that might get hooked up. But I'll probably have to disable the majority of the nice features when in 8-bit mode and provide controls similar to what the Intrepid control box is doing. And I do want it to be possible to run the Intrepid head or ones like it.

However, I can still only push reference adapter designs that spit out 16-bit PWM, and only recommend off-the-shelf LED driver bricks that support 16-bit control. (the latter being much easier to get up and running with, for hopefully obvious reasons.)

(My device isn't doing PWM directly. Its generating a DMX512 control packet, which an external box then interprets and does the PWM off of. Or in the Intrepid case, it generates a Neopixel serial control message, and the LED elements themselves do everything else.)

2. Another consideration regarding brightness and contrast:
When changing contrast below grade 4, Ilford's filters keep light tones constant.
To do that with LEDs, a contrast-change will need a corresponding brightness-change to keep the highlight probe-measurement unchanged (stationary on the display). If you simply keep G or B at its max, then a contrast-change will cause all measured points to move, which will irritate the user. I suggest keeping the rightmost point (highlight) stationary, as doing so fits well with the popular approach of setting exposure for highlights and contrast for shadows.

The manual for the Heiland B&W control box gives a table (in fictitious 0-200 unit increments) for how it maps each grade to a blue/green setting:

They actually do hit zero on either end.

I'm thinking that the most usable way to handle this is to use a table based off a similar "fictitious" unit, pick defaults like these, and then let people adjust the values if they want to. (Obviously can only do this for 16-bit. For 8-bit users, I'd likely just expose raw 0-255 values.)

So doing the thought experiment from above, if green is 200, then 6 stops below is ~3. But when applied to a 16-bit scale, 3 is 1024/65535 so there's still plenty of room for brightness adjustment.

3. A note for everyone: The Arduino Uno (ATmega328p) has only two 16-bit PWMs; the rest are 8-bit. That makes it unsuitable for color. For color, I suggest using a higher-end Arduino, or a PIC18 (works well for me), or a 32-bit MCU.

Mark

Yeah, I discovered this while researching reference options. Personally, I don't like building anything with Arduino. However, for a reference design for other people to hack on, it makes sense as a well understood and accessible baseline.

But really, its the older and more common Arduino UNO R3 (and below) that uses the ATmega328P. And its actually worse than you said. Not only does it lack the ability to do 3 channels of 16-bit PWM, it can only do 16-bit PWM at around 244Hz.

The newer Arduino UNO R4 Minima uses a Renesas RA4M1, which is a far more modern microcontroller running at a higher clock speed that's capable of doing everything you'd actually want here. (its probably overkill, actually) You just might need to code around the Arduino framework to get it to do those things.

 

[albada]

The newer Arduino UNO R4 Minima uses a Renesas RA4M1, which is a far more modern microcontroller running at a higher clock speed that's capable of doing everything you'd actually want here. (its probably overkill, actually) You just might need to code around the Arduino framework to get it to do those things.

My first controller used the Arduino Uno R3, and I had never heard of the R4 Minima, so I read some about it.
I suggest that folks not use the Arduino Uno R4 Minima for two reasons:

• It has no crystal, so you cannot accurately time anything! Its most accurate oscillator is within 1% of nominal frequency, so it could be off by 7.2 hours per month. The Uno R3 had a crystal accurate to within a few minutes per month. Why did they remove such a useful feature?
• It runs at 5 volts (like the older Arduinos), but the world has moved to 3.3 volts, and I suspect is now moving to 1.8 volts. They probably did this to be compatible with existing shields (add-on boards), but I'd prefer to use a standard that's modern and not obsolete, forcing shield-vendors to update their products.

I also read about the Renesas RA4M1 microcontroller. That thing is impressive!
Perhaps the Raspberry Pi Pico would be better than the Uno R4, as its schematic and photo show a 12 MHz crystal on board, and it can run at 1.8-5 volts according to the blurb about it. Maybe Derek could use this in his reference designs (hint hint ).

Mark

 

[dkonigs]

I also read about the Renesas RA4M1 microcontroller. That thing is impressive!
Perhaps the Raspberry Pi Pico would be better than the Uno R4, as its schematic and photo show a 12 MHz crystal on board, and it can run at 1.8-5 volts according to the blurb about it. Maybe Derek could use this in his reference designs (hint hint ).

The real problem with any "reference" design is that unless I want to get in the business of also selling Adafruit-style trinket boards as part of this project, I need solutions that can be mostly cobbled together out of off-the-shelf components. The main advantage of the standard "Arduino" form factor is the availability of peripheral shields to add a lot of the needed functionality. So there's definitely a benefit to sticking to something like that.

So it really comes down to a simple question of where to draw the dotted line on the block diagram of any "interface" widget. There are basically 3 options:
1. Mostly off-the-shelf boards that plug together, custom stuff only when absolutely required
2. Off-the-shelf microcontroller board of some sort, plugging into a carrier board with everything else
3. Completely custom board (design still open and documented)

Any of these can work. Its just that modern designs are harder for people to casually assemble, so options 2 or 3 would likely require me to actually produce the boards.

Regardless, the ultimate goal is for this design to be relatively easy and cheap for someone to cobble together as necessary. And I don't expect too many people to actually need it. (Remember, they already mass-produce DMX-controlled 16-bit LED drivers that can probably get the job done. They're just complete drivers, so they won't work with LED heads that use their own driver electronics.)