SMD. The only thing that’s thru-hole on the board is the resistor socket for the IR channel, and the Molex connectors on the back.
We picked the LEDs based on the current requirements that matched the driver we’re using, and we’re limiting ourselves to high-brightness diodes because we don’t have a ton of space on the board, so that we didn’t have to fuss with current limiting resistors per channel. That somewhat limited the choices but we were able to find the ones we needed.
Digikey has better filtering than some of the other sites, but I tend to buy from mouser, because often most parts (at least in small quantities) are a little bit cheaper there. And 2-day shipping costs the same as ground with them, so usually for $10 I have stuff in a couple days. sometimes the better way to find this stuff is to bounce between the two sites, because they each filter different types of products differently, and once you find one on one, you can just search for the mfg part number on the other to compare prices.
On the plus side, the next revision of this board should allow me to pack more on there if we need to, and with the new integrating sphere design, we don’t have to worry so much about the size of the array because we’re not trying to shoehorn it into an existing form factor.
The Integrating Sphere successfully printed last night (it was a little nerve wracking leaving it alone, but it had another 6 hours to go by the time I left yesterday). In any case, it printed up nicely, but of course, there are modifications needed, which is why I did it at low quality.
The opening at the top needs to be slightly wider, and I’m going to taper that opening in the same way the Lasergraphics gates work (a tapered 4-sided mirrored box, with the mirrors facing back down towards the sphere). Had to bust out the coping saw to make some notches on the back as well, so I’m going to incorporate those changes into the new design, as well as adding some structure on the back to help with stabilizing it against the deck plate.
Next is an aluminum bracket to hold this in place. and I also figured out why 4 of the Green LEDs weren’t working - in hooking up the drivers initially before realizing the control signal was 19V too high (oops), we fried them. So, replaced the LEDs and re-routed the jumper wire for the Blue LEDs (of which we initially had too many, so had to reduce the count), while I was in there.
Anyone know of a good source for black plastic hole plugs that fit a variety of different holes? I can only find 5mm used for cabinets, but we’re going to have so many holes on the deck plate I’d like to cover them over to make it look neater - everything from M3 to M5 sized, I think.
First color image scanned on Sasquatch, taken this afternoon. This is 15 perf IMAX, scanned at 14192x10640 pixels, 16bit per channel, separate R, G, B exposures at 8ms per exposure (faster than I thought - I think our LEDs are plenty bright!).
There’s obviously much work to do still, and this is without having painted the inside of the 3D printed integrating sphere, so it’s a little uneven across the frame still.
The fogging in the image, by the way, is because the camera module doesn’t have any flocking installed yet. The light comes in there and even though it’s black matte anodized, it reflects all over the place. This can be fixed by lining the box with self-adhesive flocking, or painting it with something like Black 3.0 paint to prevent the reflections.
Right now, it’s a gigantic sensor just some protective glass over it, open to any light that’s in the camera module, not just the projection from the back of the lens.
New LED Driver design. This version includes a DAC (lower left) to convert PWM from our ClearCore to a smooth analog signal for the driver. We essentially made a clone of the Femtobuck (right side), but because the driver chip in that is no longer available, this is with a different chip by the same manufacturer, and some minor tweaks.
There was this post a while back with a DAC controlling a power mosfet.
I think that the key is to drive the LED with steady current (rather than ON/OFF duty cycle switching). I am testing some linear power configurations taking the PWM and making it a steady current to the LEDs, once I get through the testing will post details/schematic.
This is precisely what we’re doing. The LED driver chip we are using auto-senses the input. If you give it a PWM pulse, it will control the output current based on the duty cycle of the pulse. If you input an analog voltage within a specific range (about 1V-2.5V) it scales the current proportionally to the input voltage. The DAC just converts the digital PWM pulse into analog voltage, so the LED driver can use that method of dimming.
That said, the newer LED driver we’re using shows significantly less artifacting from the PWM-only input than the interim Sparkfun driver we had in there before. That is, at 50% duty cycle, you see lines but they’re much more faint than before. The PWM frequency of the controller has not changed, this is a function of (I think) a more advanced driver chip. My bet is a higher PWM frequency might eliminate the lines entirely. Might have to test that for fun.
If you see any “stripes” in the captured image, the current driving the LED is obviously not exactly constant, or? You could check with an osciloscope.
The LED driver chip is constant current. If the PWM frequency (not the duty cycle) is faster, then it should output a steadier current. But when you measure the current with a multimeter, it’s exactly where it’s supposed to be (probably in part due to lag in the multimeter).
The Sparkfun Femtobuck and Picobuck drivers use an older version of the LED driver chip than we’re using and my guess is that instead of outputting a sine wave it’s more of a curved sawtooth. It’s somewhat smoother than the PWM square wave, but not quite enough to completely avoid the lines in the image. With the newer chip, that signal is still a sawtooth but the top of the curve is more of a plateau, with a steeper dropoff. This gets you much closer to a constant output, but isn’t quite there.
The point here is that if you want smooth dimming, use a driver chip with an analog input, use a DAC or some other method to convert PWM into smooth analog voltage within the expected range for the driver, and you will get smooth dimming with no lines.
Or, possibly, use a PWM output with a higher frequency. Our controller’s default PWM frequency is 509Hz, which is lowish. We can probably override that in the firmware and have it run faster, but we decided to add in the DAC to ensure it works ok, even if we change controllers at some point. Total parts cost is pretty minimal to add the dac.
Thank you for elaborating these details! I now understand your approach much better.
The Femtobuck you are mentioning as an inspiration for your circuit uses something like the AL8805, which is a switching converter. Now these type of things typically do work with non-constant currents. That is maybe the reason you are seeing stripes. Again, you can check this with an oscilloscope, measuring the voltage drop over a small sense-resistor in series with the LEDs.
Actually, the application note of the AL8805 suggests the following:
Reducing Output Ripple
Peak to peak ripple current in the LED(s) can be reduced, if required, by shunting a capacitor C2 across the LED(s) as shown already in the circuit schematic.
A value of 1μF will reduce the supply ripple current by a factor three (approx.). Proportionally lower ripple can be achieved with higher capacitor values. Note that the capacitor will not affect operating frequency or efficiency, but it will increase start-up delay, by reducing the rate of rise of LED voltage. By adding this capacitor the current waveform through the LED(s) changes from a triangular ramp to a more sinusoidal version without altering the mean current value.
Certainly increasing the switching frequency will help too. However, with such a switching driver-chip, the LED’s current will never be constant in the real sense, and they will flicker at least a tiny bit. Whether this matters or is noticeable at all is another story.
@friolator I would like to ask about the logarithmic conversion, I think I know the answer, but bouncing ideas helps.
The typical luminance output would be in the form of Y = Log10(X)*slope-offset, where X is the control value. The end result is that controlling X as incrementally linear input, would produce a logarithmic result at the camera video level.
For clarity, a DAC step (for example from 5 to 10) would not have the same incremental output than another 5 step at the other end of the range (let’s say from 240 to 245).
In other words, the resolution at smaller light outputs would be less than at higher outputs.
Professional equipment linearizes the controls for users, and if one is controlling it digitally it can easily be done by creating a calibration array/table or by approximating with the above function. But that reduces the steps available from the resolution of the DAC.
Is the digital approach sufficient (I think you mentioned a 12 bit DAC), is that the reason for 12 bit?
That kind of question is way beyond my art school pay grade! I won’t be doing any of that stuff (or the color science stuff), the programmer doing our firmware will handle the math, and the color science will be done by another person we’re working with. That leaves me to make a nice front end for this, more my area of expertise!
That being said, the chip we’re using is 8 bit, not 10 or 12 (for two reasons: first is that the 10 and 12 bit ones weren’t in stock. thanks, global chip shortage!. Second, our LEDs are fairly close to each other in terms of the light they output but some channels are brighter than others. Our goal is to try to keep the exposure time per color color channel consistent, because changing the exposure time in the camera software incurs a small speed hit while it’s reconfigured (so instead of altering exposure time, we’re altering LED brightness)
The thinking is to adjust the light levels to get them close to where we want them in an initial startup calibration routine (they don’t need to be perfect, just close), and then post-process the image to do the final balancing, when we’re merging the colors together into the final image (again, the color stuff is something someone else is doing for us, so I’m not the one to ask about that). Based on what I’m seeing in our initial tests, we have two ways to get things balanced:
Reduce the number of LEDs in the brighter color channels for a permanent setup that’s balanced how we want it
Reduce the intensity of the light using the same number of arrays we have now, from software
either is a feasible solution, but the second is easier because we can tweak and test in software, vs having to desolder LEDs and jumper connections. But, it requires reliable dimming that doesn’t result in lines in the image, thus all this DAC stuff (otherwise we could just run at 100% PWM duty cycle and change exposure times when needed)
I am looking at dimming to experiment with stacking images with different light levels (Mertens or Devedec), for which would be nice to control light levels, and keep the camera at the same exposure (particular limitations on my setup limit the ability to change exposures).
The reason I ask is because is part of the LED driver. If the LED is driven by a staircase the light produced is a logarithmic staircase.
So if instead of driving the LEDs with a linear stair, it is driven with a non-linear amplifier (have to figure out if it is a log or antilog amplifier), then the result would be equivalent to changing the X axis to a log scale.
If the color science guy after doesn’t have the resolution (because of the non-linear nature of the light) then it is too late to fix it. This compensation can be done digitally, as long as the resolution at the lower part of the range (due to the curve) is enough.
What is beyond my tech paygrade is what is a good light resolution for using scanning light for corrections.
In your case, it is adding an OpAmp in the right configuration (log or antilog) between the DAC and the regulator.
After some pillow time, and additional testing, I think 8 bit is most likely not enough for colors.
The steps at the bottom of the curve (below 50 on the level captures = below 25% power) are on the steep slope of the curve.
Did you consider using a 16bit PWM? (given the shortage of DACs mentioned above)
I prototyped the driver and do see something odd, but I think is the electronic shutter, just because I do not see any corresponding current. Take a look at testing of the16 bit PWM driving 3 x 1W white LEDs
@matthewepler this is based on the draft I shared. Would like to expend a bit more time understanding the fluttering at low currents, which may be an issue for the color LEDs.
I’m definitely out of my league here in terms of electronics knowledge. I do, however, agree that the higher the resolution of DAC, the better. Those results look pretty great to me. What’s providing that 16-bit resolution PWM signal? The Clear Core?
And that’s hitting your DAC → Op Amp setup, correct?
@PM490 has sketched out a current mirroring circuit that may allow for smoother control with a smaller resolution of PWM. He can tell you more about it.
PS thanks for the video showing off the brightness control + scope output. That was good content
@friolator Higher PWM will not eliminate the noise/ripple, it may make it less noticeable but the artifacts would still be in the picture. After expending a bit more time chasing lines/noise, I found that at low light, even the slightest ripple noise is passed by the LEDs to the image. Want it to mention that in case some of the noise you are seeing is coming from the power supply.
In my case, the ATX power supply had a light load (switching power supplies regulate better under load conditions). The 12V is putting out a 5mV to 30mV ripple when power consumption is at the lowest, and the frequency was about 130 Hz, so it was easy to see in the resulting picture. Hope this information helps on troubleshooting your driver.
While we try to sort out some electronics issues, I’m catching up on a bunch of things I’ve gotten behind on - like making cables for the camera/lens stage, and getting the reflections out of the camera box. Amazing what a difference $4 in craft flocking makes!
