Feedback on sync ideas for open-source LED driver

[Benjamin Smith]

*****
To join, leave or search the confocal microscopy listserv, go to:
http://lists.umn.edu/cgi-bin/wa?A0=confocalmicroscopy
Post images on http://www.imgur.com and include the link in your posting.
*****

Hey Microscopists,

I am currently working on designing the graphical user interface for an
open-source high-speed LED driver, and was hoping to get some feedback on
ideas for built-in syncing options.

For reference, the driver itself has four LED channels, >3 MHz bandwidth,
can drive up to four <1.5A LEDs or one <40A LED.  The on-board
microcontroller is a Teensy 3.6.  This is also the current layout for the
GUI:

Main panel - https://bit.ly/3pWzqJi
Configure panel - https://bit.ly/33gsxJf
Calibration panel - https://bit.ly/3pZwXO7
Staus: text - https://bit.ly/2UUIzno
Status: graph - https://bit.ly/2UW2DWm

These are the sync inputs I'm thinking of:

*Confocal* - sync an LED to the scanning mirrors of a laser scanning
confocal microscope
- Analog (4 µs latency) - sync to the analog voltage driving the fast (x)
mirror.
- Digital (40 ns latency) - sync to a line clock output (ideal for resonant
systems)

*Digital* - sync to a digital input (such as a camera TTL output)

*Analog*
- Mirroring (5 us latency) - use the ADC to read an analog input, and then
mirror that input onto the DAC controlling the driver.  This will allow for
preserving programmed current limits and protect the driver from over/under
voltages.
- Direct (minimal latency) - directly port an input analog signal to the
op-amp controlling the LED current.  Fastest possible drive speed, but will
override programmed current limits (a warning window will definitely pop up
before activating this mode).

*Arbitrary wave generator (AWG)*
- Internal memory - pre-load an arbitrary wave function onto theTeensy SD
card or load over serial
- Real-time serial - play an arbitrary wave function streamed in real-time
over serial

*Macro* (for LED channel sequencing, for-loops, etc.)
- Dedicated Teensy function - program a dedicated custom function in the
Teensy source code in C++ that is then called by the GUI.  This will allow
for very low latency sync regimens
- Serial through GUI - Write a sync macro in Python within the GUI itself,
and the program will then coordinate the sync with the driver over serial.
This will have higher latency (not yet tested but likely around10-100 us),
but will allow much simpler coding of custom sync regimens.

*FLIM?* - Given the LED driver's speed, would it also be worthwhile to add
a FLIM mode?

As this is a solo project, any feedback would be much appreciated.

Cheers,
   Ben Smith

--
Benjamin E. Smith, Ph. D.
Imaging Specialist, Vision Science
University of California, Berkeley
195 Life Sciences Addition
Berkeley, CA  94720-3200
Tel  [phone]
Fax [phone]
e-mail: [hidden email]
https://vision.berkeley.edu/faculty/core-grants-nei/core-grant-microscopic-imaging/

[Gordon Scott-3]

*****
To join, leave or search the confocal microscopy listserv, go to:
http://lists.umn.edu/cgi-bin/wa?A0=confocalmicroscopy
Post images on http://www.imgur.com and include the link in your posting.
*****

Hi Benjamin,

After the disgusting way my ex-employer treated me, I definitely should
be working on this.

Please mail me links and/or data that I may have a look at the project
as a whole.

Thanks.

Kind regards,

                          Gordon.

On 24/11/2020 20:21, Benjamin Smith wrote:

> *****
> To join, leave or search the confocal microscopy listserv, go to:
> http://lists.umn.edu/cgi-bin/wa?A0=confocalmicroscopy
> Post images on http://www.imgur.com and include the link in your posting.
> *****
>
> Hey Microscopists,
>
> I am currently working on designing the graphical user interface for an
> open-source high-speed LED driver, and was hoping to get some feedback on
> ideas for built-in syncing options.
>

[Anthony Clearn]

*****
To join, leave or search the confocal microscopy listserv, go to:
http://lists.umn.edu/cgi-bin/wa?A0=confocalmicroscopy
Post images on http://www.imgur.com and include the link in your posting.
*****

It might be useful to consider websockets

https://diyprojects.io/websocket-communication-esp8266-arduino-python-test-ws4py-library-raspberry-pi/#.X75G5rOnxaQ

hth,
a.

  1. Feedback on sync ideas for open-source LED driver

----------------------------------------------------------------------

Date:    Tue, 24 Nov 2020 12:21:15 -0800
From:    Benjamin Smith <[hidden email]>
Subject: Feedback on sync ideas for open-source LED driver

*****
To join, leave or search the confocal microscopy listserv, go to:
http://lists.umn.edu/cgi-bin/wa?A0=confocalmicroscopy
Post images on http://www.imgur.com and include the link in your posting.
*****

Hey Microscopists,

I am currently working on designing the graphical user interface for an open-source high-speed LED driver, and was hoping to get some feedback on ideas for built-in syncing options.

For reference, the driver itself has four LED channels, >3 MHz bandwidth, can drive up to four <1.5A LEDs or one <40A LED.  The on-board microcontroller is a Teensy 3.6.  This is also the current layout for the
GUI:

Main panel - https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fbit.ly%2f3pWzqJi&c=E,1,Zc6gSDb3ppvZRQ30KRTB7JqvSYW0izEnURc1eu8mJ1oRAyNxk_vnK4GlivjqypskwtAH-CxVNhlP8mI59qK09wb942Io5h-CLC_bB5GyEVOlS8ivcykMXTIp0w,,&typo=1
Configure panel - https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fbit.ly%2f33gsxJf&c=E,1,pX40f1cJ74ZvvyGRZ3AWXOwjos774BalB4Tm-zYyx4FAcU1bzfaB83Rh38GnhV_q5a_GSzQHKCo1K8FbcufTohMPuQ_9IlLNaYKkiD2NgROGzt-Edc0,&typo=1
Calibration panel - https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fbit.ly%2f3pZwXO7&c=E,1,3odXdKCGf7ohqKBXzq-x6hBDALG7uq5SL8xqdYT3N4wOGvmszw9qyGVJA_IggvNqOoTDEkFCWo0AKrD58-RlUwr64DsmuqcnZsmkwBSceucsBORU&typo=1
Staus: text - https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fbit.ly%2f2UUIzno&c=E,1,RFM-lkiKvOCDDNAYNssz4mFD8HtXoSSKUvlsCFas4k1vN2YDSreBVi_UW4-GOPmAHPCyVgmPbPbA5-qj0lTZAtIQdTirn60lsRvJz2PzJT8,&typo=1
Status: graph - https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fbit.ly%2f2UW2DWm&c=E,1,xY0ivl0orJzcZNdd3_x6YoVH5VZXQyMoIIOyEembpq5M8Kf99sxSTt9lMKCDw9DZ4yAFOHxqW2GIDJifOnbje0tcZ8uYmNz17Wm98-X1iuk8UEs52EZO2A,,&typo=1

These are the sync inputs I'm thinking of:

*Confocal* - sync an LED to the scanning mirrors of a laser scanning confocal microscope
- Analog (4 µs latency) - sync to the analog voltage driving the fast (x) mirror.
- Digital (40 ns latency) - sync to a line clock output (ideal for resonant
systems)

*Digital* - sync to a digital input (such as a camera TTL output)

*Analog*
- Mirroring (5 us latency) - use the ADC to read an analog input, and then mirror that input onto the DAC controlling the driver.  This will allow for preserving programmed current limits and protect the driver from over/under voltages.
- Direct (minimal latency) - directly port an input analog signal to the op-amp controlling the LED current.  Fastest possible drive speed, but will override programmed current limits (a warning window will definitely pop up before activating this mode).

*Arbitrary wave generator (AWG)*
- Internal memory - pre-load an arbitrary wave function onto theTeensy SD card or load over serial
- Real-time serial - play an arbitrary wave function streamed in real-time over serial

*Macro* (for LED channel sequencing, for-loops, etc.)
- Dedicated Teensy function - program a dedicated custom function in the Teensy source code in C++ that is then called by the GUI.  This will allow for very low latency sync regimens
- Serial through GUI - Write a sync macro in Python within the GUI itself, and the program will then coordinate the sync with the driver over serial.
This will have higher latency (not yet tested but likely around10-100 us), but will allow much simpler coding of custom sync regimens.

*FLIM?* - Given the LED driver's speed, would it also be worthwhile to add a FLIM mode?

As this is a solo project, any feedback would be much appreciated.

Cheers,
   Ben Smith

[Benjamin Smith]

*****
To join, leave or search the confocal microscopy listserv, go to:
http://lists.umn.edu/cgi-bin/wa?A0=confocalmicroscopy
Post images on http://www.imgur.com and include the link in your posting.
*****

Hey Gordon,

The project is in a Github repository that can be found here:
https://github.com/Llamero/Four_Channel_MHz_LED_Driver  The project is
fully open-source, so the PCB design is licensed under the Creative Commons
Attribution-ShareAlike 4.0 license, and the software is licensed under the
Apache 2.0 license.

Note that the project is still very much in development, so the repository
is currently organized to help me workout the design, as opposed to
something meant for public consumption.  That said, the repository includes
the LTSpice files used to simulate the driver, the KiCAD project file,
Gerber files, and the driver (C++) and GUI (Python) code  - mostly test
pieces right now.

So that you don't have to clone the KiCAD project on your own computer just
to get an overview here are some reference images:
Schematic - https://bit.ly/3l0aDAo
CAD model - https://bit.ly/39gRmZ6
Physical driver - https://bit.ly/37byFUf
Note that the driver also has an enclosure designed that is not shown.

Below is a more detailed description of the design and operation (i.e. TMI):

One of the main design principles was to make the driver easy to build by
anyone (i.e. requires no special skills or tools) and easy to integrate
into existing systems.  Along these lines, all components are surface mount
so that there is no hand soldering and the driver can basically be built
like a miniature Lego kit.  Additionally, all connections to the driver are
though a 4x RJ45 connector on the back.  This allows one ethernet cable to
carry the equivalent signals of four BNC cables, and can easily be
connected to BNC jacks/cables with a RJ45-BNC balun: https://amzn.to/3pVmzqV
The four LED channels are also output through a RJ45 connector as CAT5
cable is ideal for driving standard 1A LEDs with over 1 MHz bandwidth, and
the four channels can even be pooled to allow for one 4A device (such as a
high power diode laser) to be driven through the RJ45 jack.  For higher
power connections (such as 30A LEDs), there are wire pads on the PCB itself.

The driver is designed as a single layer MCPCB.  This allows it to handle
over 100W of heating and therefore making it capable of a high current
limit (as the driver is basically a high speed linear regulator).  The core
of the driver is the crazy fast LT6200-10 1.6 GHz op-amp driving a power
DPAK n-mosfet.  To allow the driver to be optimally tuned for a wide array
of possible LEDs and wiring, there are a pair of trimpots that allow for
adjustable compensation of the op-amp (one more or less adjusts the speed
of the driver, and the other more or less other adjusts the damping
coefficient of the driver).  There are then four slots for current sense
resistors to allow for a wide range of current outputs for the driver.
Since the op-amp can handle 12V and most power mosfets have a min Rds on of
10V, the opamp is powered by a +10V/-1.8V split rail.  Finally, for high
current applications, there is also a TVS diode protecting the mosfet.

The driver output is connected to four SSRs which act as a mux to allow for
four separate LEDs to be driven by the same core driver, with a switch time
between channels of about 100 µs.  For high current use, there are a pair
of solder pads on the PCB for connecting wire leads for both the high
power LED and the power supply.

For sync/trigger inputs, there are four analog/digital inputs with a
4.7kOhm impedance and a 0-3.3V clamp.  The clamp is important, as not only
does it allow for connection to 5V TTL signals, but also to analog mirror
voltages which normally range from +7V to -7V.  The maximum rated voltage
range for the inputs is +20V/-17V.  There is also an input that allows for
directly driving the op-amp using an external analog signal (as opposed to
using the internal DAC).  There is also an input available for connecting
an external thermistor (such as those often found on high power LEDs to
monitor LED temperature).  Finally, one of the I2C buses is also available
as an optional output/input.

For sync/trigger outputs, there are three buffered 5V/16mA outputs that are
all PWM capable.  The 5V PWM allows for driving external fans, which can be
useful when using high power LEDs, especially since the driver can also
monitor LED temperature.  The current sense voltage is also connected as an
output, with a series 100 ohm resistor to protect against accidentally
shorting the current sense voltage (which would be very bad).  This current
sense output voltage is also connected to an analog pin on the Teensy,
allowing internal monitoring of LED current as well.

For user inputs, there is a toggle switch, four illuminated pushbuttons and
a potentiometer.  The toggle switch is used to switch the driver between
manual and sync mode.  The potentiometer allows for the LED intensity to be
adjusted.  The pushbuttons will allow for switching between the four LED
channels with the illumination indicating the active channel.  The
illumination will also be used to warn of any fault status.

Since the driver is designed to run at high powers, there is also
integrated temperature monitoring, with one thermistor monitoring the
mosfet temperature, and another thermistor monitoring the current sense
resistor temperature.  This way, the driver can automatically turn off the
LED current if the driver or LED starts to overheat, protecting both the
driver and LED.  There is also a piezo transducer to generate an audible
alarm in the event of an overheating fault.  The driver also is designed to
be connected to a standard 4-pin 92 mm computer fan for cooling of the
driver itself, and can control the fan speed using 5V PWM.

If you have any further questions, please feel free to ask.

Cheers,
   Ben Smith


On Wed, Nov 25, 2020 at 4:03 AM Gordon Scott <[hidden email]> wrote:

> *****
> To join, leave or search the confocal microscopy listserv, go to:
> http://lists.umn.edu/cgi-bin/wa?A0=confocalmicroscopy
> Post images on http://www.imgur.com and include the link in your posting.
> *****
>
> Hi Benjamin,
>
> After the disgusting way my ex-employer treated me, I definitely should
> be working on this.
>
> Please mail me links and/or data that I may have a look at the project
> as a whole.
>
> Thanks.
>
> Kind regards,
>
>                           Gordon.
>
> On 24/11/2020 20:21, Benjamin Smith wrote:
> > *****
> > To join, leave or search the confocal microscopy listserv, go to:
> > http://lists.umn.edu/cgi-bin/wa?A0=confocalmicroscopy
> > Post images on http://www.imgur.com and include the link in your
> posting.
> > *****
> >
> > Hey Microscopists,
> >
> > I am currently working on designing the graphical user interface for an
> > open-source high-speed LED driver, and was hoping to get some feedback on
> > ideas for built-in syncing options.
> >
>

--
Benjamin E. Smith, Ph. D.
Imaging Specialist, Vision Science
University of California, Berkeley
195 Life Sciences Addition
Berkeley, CA  94720-3200
Tel  [phone]
Fax [phone]
e-mail: [hidden email]
https://vision.berkeley.edu/faculty/core-grants-nei/core-grant-microscopic-imaging/

[Benjamin Smith]

*****
To join, leave or search the confocal microscopy listserv, go to:
http://lists.umn.edu/cgi-bin/wa?A0=confocalmicroscopy
Post images on http://www.imgur.com and include the link in your posting.
*****

Hey Anthony,

I was initially thinking of TCP (hadn't heard of websockets though, thanks
for the tip), but the speed penalty for TCP was the biggest issue.  For
example, when synced to a 16 kHz resonant microscope, the microcontroller
only has about 20 µs to complete any task before it needs to start watching
for the next trigger event.  Therefore, any serial protocol needs to be
able to be broken up into a set of smaller subtasks where no single task
ever takes more than about 15 µs (to ensure a bit of a time buffer).  On
the Teensy, USB serial tasks can be broken into smaller subtasks such as by
loading only a few bytes of data into the USB buffer at a time.
Transmission of the USB buffer is executed by a separate chip, which then
frees up the MCU to do other tasks.  While I do lose the security of TCP,
the USB protocol still has CRC built into the protocol (learned this the
hard way), so I still get some degree of protection from data corruption.
 I also realized that I only need TCP level data security for things like
uploading configuration data to the driver (which is not time sensitive),
and that streaming data such as the status of the driver is not data
critical, as if the GUI receives a bad status packet, it will only be at
most a tenth of a second before it gets another status update.  Therefore,
my idea was to just manually do a TCP style handshake for the
configuration, and a simple data stream for the status updates to the GUI.
That said, if you know of a <15 µs implementation of websockets on the
Teensy, I would definitely like to hear more about it.

Thanks again for the tip,
   Ben Smith



On Wed, Nov 25, 2020 at 4:15 AM Anthony Clearn <
[hidden email]> wrote:

> *****
> To join, leave or search the confocal microscopy listserv, go to:
> http://lists.umn.edu/cgi-bin/wa?A0=confocalmicroscopy
> Post images on http://www.imgur.com and include the link in your posting.
> *****
>
> It might be useful to consider websockets
>
>
> https://diyprojects.io/websocket-communication-esp8266-arduino-python-test-ws4py-library-raspberry-pi/#.X75G5rOnxaQ
>
> hth,
> a.
>
>   1. Feedback on sync ideas for open-source LED driver
>
> ----------------------------------------------------------------------
>
> Date:    Tue, 24 Nov 2020 12:21:15 -0800
> From:    Benjamin Smith <[hidden email]>
> Subject: Feedback on sync ideas for open-source LED driver
>
> *****
> To join, leave or search the confocal microscopy listserv, go to:
> http://lists.umn.edu/cgi-bin/wa?A0=confocalmicroscopy
> Post images on http://www.imgur.com and include the link in your posting.
> *****
>
> Hey Microscopists,
>
> I am currently working on designing the graphical user interface for an
> open-source high-speed LED driver, and was hoping to get some feedback on
> ideas for built-in syncing options.
>
> For reference, the driver itself has four LED channels, >3 MHz bandwidth,
> can drive up to four <1.5A LEDs or one <40A LED.  The on-board
> microcontroller is a Teensy 3.6.  This is also the current layout for the
> GUI:
>
> Main panel -
> https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fbit.ly%2f3pWzqJi&c=E,1,Zc6gSDb3ppvZRQ30KRTB7JqvSYW0izEnURc1eu8mJ1oRAyNxk_vnK4GlivjqypskwtAH-CxVNhlP8mI59qK09wb942Io5h-CLC_bB5GyEVOlS8ivcykMXTIp0w,,&typo=1
> Configure panel -
> https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fbit.ly%2f33gsxJf&c=E,1,pX40f1cJ74ZvvyGRZ3AWXOwjos774BalB4Tm-zYyx4FAcU1bzfaB83Rh38GnhV_q5a_GSzQHKCo1K8FbcufTohMPuQ_9IlLNaYKkiD2NgROGzt-Edc0,&typo=1
> Calibration panel -
> https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fbit.ly%2f3pZwXO7&c=E,1,3odXdKCGf7ohqKBXzq-x6hBDALG7uq5SL8xqdYT3N4wOGvmszw9qyGVJA_IggvNqOoTDEkFCWo0AKrD58-RlUwr64DsmuqcnZsmkwBSceucsBORU&typo=1
> Staus: text -
> https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fbit.ly%2f2UUIzno&c=E,1,RFM-lkiKvOCDDNAYNssz4mFD8HtXoSSKUvlsCFas4k1vN2YDSreBVi_UW4-GOPmAHPCyVgmPbPbA5-qj0lTZAtIQdTirn60lsRvJz2PzJT8,&typo=1
> Status: graph -
> https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fbit.ly%2f2UW2DWm&c=E,1,xY0ivl0orJzcZNdd3_x6YoVH5VZXQyMoIIOyEembpq5M8Kf99sxSTt9lMKCDw9DZ4yAFOHxqW2GIDJifOnbje0tcZ8uYmNz17Wm98-X1iuk8UEs52EZO2A,,&typo=1
>
> These are the sync inputs I'm thinking of:
>
> *Confocal* - sync an LED to the scanning mirrors of a laser scanning
> confocal microscope
> - Analog (4 µs latency) - sync to the analog voltage driving the fast (x)
> mirror.
> - Digital (40 ns latency) - sync to a line clock output (ideal for resonant
> systems)
>
> *Digital* - sync to a digital input (such as a camera TTL output)
>
> *Analog*
> - Mirroring (5 us latency) - use the ADC to read an analog input, and then
> mirror that input onto the DAC controlling the driver.  This will allow for
> preserving programmed current limits and protect the driver from over/under
> voltages.
> - Direct (minimal latency) - directly port an input analog signal to the
> op-amp controlling the LED current.  Fastest possible drive speed, but will
> override programmed current limits (a warning window will definitely pop up
> before activating this mode).
>
> *Arbitrary wave generator (AWG)*
> - Internal memory - pre-load an arbitrary wave function onto theTeensy SD
> card or load over serial
> - Real-time serial - play an arbitrary wave function streamed in real-time
> over serial
>
> *Macro* (for LED channel sequencing, for-loops, etc.)
> - Dedicated Teensy function - program a dedicated custom function in the
> Teensy source code in C++ that is then called by the GUI.  This will allow
> for very low latency sync regimens
> - Serial through GUI - Write a sync macro in Python within the GUI itself,
> and the program will then coordinate the sync with the driver over serial.
> This will have higher latency (not yet tested but likely around10-100 us),
> but will allow much simpler coding of custom sync regimens.
>
> *FLIM?* - Given the LED driver's speed, would it also be worthwhile to add
> a FLIM mode?
>
> As this is a solo project, any feedback would be much appreciated.
>
> Cheers,
>    Ben Smith
>

--
Benjamin E. Smith, Ph. D.
Imaging Specialist, Vision Science
University of California, Berkeley
195 Life Sciences Addition
Berkeley, CA  94720-3200
Tel  [phone]
Fax [phone]
e-mail: [hidden email]
https://vision.berkeley.edu/faculty/core-grants-nei/core-grant-microscopic-imaging/

[Zdenek Svindrych-2]

*****
To join, leave or search the confocal microscopy listserv, go to:
http://lists.umn.edu/cgi-bin/wa?A0=confocalmicroscopy
Post images on http://www.imgur.com and include the link in your posting.
*****

Hi Ben,

impressive effort.
But "...start watching for the next trigger event..." is the wrong
approach. You should try to encode all the logic into the PWMs/timers (they
are very flexible), or through interrupts (analog comparators or external
comparators; any pin change can also raise an interrupt). Not sure how to
implement this in Teensy-arduino (or whatever tools you're using), but
assuming something's gonna happen in 1/16 ms is just waiting for a
disaster. Use interrupts for sort-of-time-critical stuff, the rest (comm,
ethernet, USB) is handled through FIFOs in it's own pace.

*Disclaimer* The above is just a theory.

Good luck!
zdenek

On Wed, Nov 25, 2020 at 2:50 PM Benjamin Smith <[hidden email]>
wrote:

> *****
> To join, leave or search the confocal microscopy listserv, go to:
> http://lists.umn.edu/cgi-bin/wa?A0=confocalmicroscopy
> Post images on http://www.imgur.com and include the link in your posting.
> *****
>
> Hey Anthony,
>
> I was initially thinking of TCP (hadn't heard of websockets though, thanks
> for the tip), but the speed penalty for TCP was the biggest issue.  For
> example, when synced to a 16 kHz resonant microscope, the microcontroller
> only has about 20 µs to complete any task before it needs to start watching
> for the next trigger event.  Therefore, any serial protocol needs to be
> able to be broken up into a set of smaller subtasks where no single task
> ever takes more than about 15 µs (to ensure a bit of a time buffer).  On
> the Teensy, USB serial tasks can be broken into smaller subtasks such as by
> loading only a few bytes of data into the USB buffer at a time.
> Transmission of the USB buffer is executed by a separate chip, which then
> frees up the MCU to do other tasks.  While I do lose the security of TCP,
> the USB protocol still has CRC built into the protocol (learned this the
> hard way), so I still get some degree of protection from data corruption.
>  I also realized that I only need TCP level data security for things like
> uploading configuration data to the driver (which is not time sensitive),
> and that streaming data such as the status of the driver is not data
> critical, as if the GUI receives a bad status packet, it will only be at
> most a tenth of a second before it gets another status update.  Therefore,
> my idea was to just manually do a TCP style handshake for the
> configuration, and a simple data stream for the status updates to the GUI.
> That said, if you know of a <15 µs implementation of websockets on the
> Teensy, I would definitely like to hear more about it.
>
> Thanks again for the tip,
>    Ben Smith
>
>
>
> On Wed, Nov 25, 2020 at 4:15 AM Anthony Clearn <
> [hidden email]> wrote:
>
> > *****
> > To join, leave or search the confocal microscopy listserv, go to:
> > http://lists.umn.edu/cgi-bin/wa?A0=confocalmicroscopy
> > Post images on http://www.imgur.com and include the link in your
> posting.
> > *****
> >
> > It might be useful to consider websockets
> >
> >
> >
> https://diyprojects.io/websocket-communication-esp8266-arduino-python-test-ws4py-library-raspberry-pi/#.X75G5rOnxaQ
> >
> > hth,
> > a.
> >
> >   1. Feedback on sync ideas for open-source LED driver
> >
> > ----------------------------------------------------------------------
> >
> > Date:    Tue, 24 Nov 2020 12:21:15 -0800
> > From:    Benjamin Smith <[hidden email]>
> > Subject: Feedback on sync ideas for open-source LED driver
> >
> > *****
> > To join, leave or search the confocal microscopy listserv, go to:
> > http://lists.umn.edu/cgi-bin/wa?A0=confocalmicroscopy
> > Post images on http://www.imgur.com and include the link in your
> posting.
> > *****
> >
> > Hey Microscopists,
> >
> > I am currently working on designing the graphical user interface for an
> > open-source high-speed LED driver, and was hoping to get some feedback on
> > ideas for built-in syncing options.
> >
> > For reference, the driver itself has four LED channels, >3 MHz bandwidth,
> > can drive up to four <1.5A LEDs or one <40A LED.  The on-board
> > microcontroller is a Teensy 3.6.  This is also the current layout for the
> > GUI:
> >
> > Main panel -
> >
> https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fbit.ly%2f3pWzqJi&c=E,1,Zc6gSDb3ppvZRQ30KRTB7JqvSYW0izEnURc1eu8mJ1oRAyNxk_vnK4GlivjqypskwtAH-CxVNhlP8mI59qK09wb942Io5h-CLC_bB5GyEVOlS8ivcykMXTIp0w,,&typo=1
> > Configure panel -
> >
> https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fbit.ly%2f33gsxJf&c=E,1,pX40f1cJ74ZvvyGRZ3AWXOwjos774BalB4Tm-zYyx4FAcU1bzfaB83Rh38GnhV_q5a_GSzQHKCo1K8FbcufTohMPuQ_9IlLNaYKkiD2NgROGzt-Edc0,&typo=1
> > Calibration panel -
> >
> https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fbit.ly%2f3pZwXO7&c=E,1,3odXdKCGf7ohqKBXzq-x6hBDALG7uq5SL8xqdYT3N4wOGvmszw9qyGVJA_IggvNqOoTDEkFCWo0AKrD58-RlUwr64DsmuqcnZsmkwBSceucsBORU&typo=1
> > Staus: text -
> >
> https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fbit.ly%2f2UUIzno&c=E,1,RFM-lkiKvOCDDNAYNssz4mFD8HtXoSSKUvlsCFas4k1vN2YDSreBVi_UW4-GOPmAHPCyVgmPbPbA5-qj0lTZAtIQdTirn60lsRvJz2PzJT8,&typo=1
> > Status: graph -
> >
> https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fbit.ly%2f2UW2DWm&c=E,1,xY0ivl0orJzcZNdd3_x6YoVH5VZXQyMoIIOyEembpq5M8Kf99sxSTt9lMKCDw9DZ4yAFOHxqW2GIDJifOnbje0tcZ8uYmNz17Wm98-X1iuk8UEs52EZO2A,,&typo=1
> >
> > These are the sync inputs I'm thinking of:
> >
> > *Confocal* - sync an LED to the scanning mirrors of a laser scanning
> > confocal microscope
> > - Analog (4 µs latency) - sync to the analog voltage driving the fast (x)
> > mirror.
> > - Digital (40 ns latency) - sync to a line clock output (ideal for
> resonant
> > systems)
> >
> > *Digital* - sync to a digital input (such as a camera TTL output)
> >
> > *Analog*
> > - Mirroring (5 us latency) - use the ADC to read an analog input, and
> then
> > mirror that input onto the DAC controlling the driver.  This will allow
> for
> > preserving programmed current limits and protect the driver from
> over/under
> > voltages.
> > - Direct (minimal latency) - directly port an input analog signal to the
> > op-amp controlling the LED current.  Fastest possible drive speed, but
> will
> > override programmed current limits (a warning window will definitely pop
> up
> > before activating this mode).
> >
> > *Arbitrary wave generator (AWG)*
> > - Internal memory - pre-load an arbitrary wave function onto theTeensy SD
> > card or load over serial
> > - Real-time serial - play an arbitrary wave function streamed in
> real-time
> > over serial
> >
> > *Macro* (for LED channel sequencing, for-loops, etc.)
> > - Dedicated Teensy function - program a dedicated custom function in the
> > Teensy source code in C++ that is then called by the GUI.  This will
> allow
> > for very low latency sync regimens
> > - Serial through GUI - Write a sync macro in Python within the GUI
> itself,
> > and the program will then coordinate the sync with the driver over
> serial.
> > This will have higher latency (not yet tested but likely around10-100
> us),
> > but will allow much simpler coding of custom sync regimens.
> >
> > *FLIM?* - Given the LED driver's speed, would it also be worthwhile to
> add
> > a FLIM mode?
> >
> > As this is a solo project, any feedback would be much appreciated.
> >
> > Cheers,
> >    Ben Smith
> >
>
>
> --
> Benjamin E. Smith, Ph. D.
> Imaging Specialist, Vision Science
> University of California, Berkeley
> 195 Life Sciences Addition
> Berkeley, CA  94720-3200
> Tel  [phone]
> Fax [phone]
> e-mail: [hidden email]
>
> https://vision.berkeley.edu/faculty/core-grants-nei/core-grant-microscopic-imaging/
>

--
--
Zdenek Svindrych, Ph.D.
Research Scientist - Microscopy Imaging Specialist
Department of Biochemistry and Cell Biology
Geisel School of Medicine at Dartmouth

[Zdenek Svindrych-2]

*****
To join, leave or search the confocal microscopy listserv, go to:
http://lists.umn.edu/cgi-bin/wa?A0=confocalmicroscopy
Post images on http://www.imgur.com and include the link in your posting.
*****

Hi Ben,
thanks for sharing!
Your "linear" approach seems straightforward enough, but you need 1 teensy
per 1 LED. OK, why not. But it may not be as fast as you think, to
charge/discharge the FET gate (maybe 20 nC) with 60 mA opamp may take 400
ns (depending on LED current).
Which brings me to the other thing, it won't be scalable to high current
LEDs. I'm not a big fan of big LEDs and I think most things can be
achieved with 1mm x 1mm LEDs (2 Amps), but depending on application (and o
your V_in), the dissipation in your FET (and/or resistors) may be way more
than the LED power...
One solution is to decrease the V_in with a buck PWM (I've seen something
like this in some CoolLed light sources), but a real pro would use current
mode PWM (to set the LED current) and shunt FET (to turn the led on/off
quickly). Something like DK-114N driver board from PhlatLight, using
LM3433, a typical schematic is here:
https://www.ti.com/lit/ug/snva327b/snva327b.pdf but it's terrible to read.
The whole trick is that when the LED is shorted by the FET, there is very
little dissipation...
Of course if you drive a white LED, you're eventually limited by the slow
response of the phosphor.
Anyway, I appreciate what you've built so far, it's orders of magnitude
better than my creations :-)
Best, zdenek

On Wed, Nov 25, 2020 at 2:35 PM Benjamin Smith <[hidden email]>
wrote:

> *****
> To join, leave or search the confocal microscopy listserv, go to:
> http://lists.umn.edu/cgi-bin/wa?A0=confocalmicroscopy
> Post images on http://www.imgur.com and include the link in your posting.
> *****
>
> Hey Gordon,
>
> The project is in a Github repository that can be found here:
> https://github.com/Llamero/Four_Channel_MHz_LED_Driver  The project is
> fully open-source, so the PCB design is licensed under the Creative Commons
> Attribution-ShareAlike 4.0 license, and the software is licensed under the
> Apache 2.0 license.
>
> Note that the project is still very much in development, so the repository
> is currently organized to help me workout the design, as opposed to
> something meant for public consumption.  That said, the repository includes
> the LTSpice files used to simulate the driver, the KiCAD project file,
> Gerber files, and the driver (C++) and GUI (Python) code  - mostly test
> pieces right now.
>
> So that you don't have to clone the KiCAD project on your own computer just
> to get an overview here are some reference images:
> Schematic - https://bit.ly/3l0aDAo
> CAD model - https://bit.ly/39gRmZ6
> Physical driver - https://bit.ly/37byFUf
> Note that the driver also has an enclosure designed that is not shown.
>
> Below is a more detailed description of the design and operation (i.e.
> TMI):
>
> One of the main design principles was to make the driver easy to build by
> anyone (i.e. requires no special skills or tools) and easy to integrate
> into existing systems.  Along these lines, all components are surface mount
> so that there is no hand soldering and the driver can basically be built
> like a miniature Lego kit.  Additionally, all connections to the driver are
> though a 4x RJ45 connector on the back.  This allows one ethernet cable to
> carry the equivalent signals of four BNC cables, and can easily be
> connected to BNC jacks/cables with a RJ45-BNC balun:
> https://amzn.to/3pVmzqV
> The four LED channels are also output through a RJ45 connector as CAT5
> cable is ideal for driving standard 1A LEDs with over 1 MHz bandwidth, and
> the four channels can even be pooled to allow for one 4A device (such as a
> high power diode laser) to be driven through the RJ45 jack.  For higher
> power connections (such as 30A LEDs), there are wire pads on the PCB
> itself.
>
> The driver is designed as a single layer MCPCB.  This allows it to handle
> over 100W of heating and therefore making it capable of a high current
> limit (as the driver is basically a high speed linear regulator).  The core
> of the driver is the crazy fast LT6200-10 1.6 GHz op-amp driving a power
> DPAK n-mosfet.  To allow the driver to be optimally tuned for a wide array
> of possible LEDs and wiring, there are a pair of trimpots that allow for
> adjustable compensation of the op-amp (one more or less adjusts the speed
> of the driver, and the other more or less other adjusts the damping
> coefficient of the driver).  There are then four slots for current sense
> resistors to allow for a wide range of current outputs for the driver.
> Since the op-amp can handle 12V and most power mosfets have a min Rds on of
> 10V, the opamp is powered by a +10V/-1.8V split rail.  Finally, for high
> current applications, there is also a TVS diode protecting the mosfet.
>
> The driver output is connected to four SSRs which act as a mux to allow for
> four separate LEDs to be driven by the same core driver, with a switch time
> between channels of about 100 µs.  For high current use, there are a pair
> of solder pads on the PCB for connecting wire leads for both the high
> power LED and the power supply.
>
> For sync/trigger inputs, there are four analog/digital inputs with a
> 4.7kOhm impedance and a 0-3.3V clamp.  The clamp is important, as not only
> does it allow for connection to 5V TTL signals, but also to analog mirror
> voltages which normally range from +7V to -7V.  The maximum rated voltage
> range for the inputs is +20V/-17V.  There is also an input that allows for
> directly driving the op-amp using an external analog signal (as opposed to
> using the internal DAC).  There is also an input available for connecting
> an external thermistor (such as those often found on high power LEDs to
> monitor LED temperature).  Finally, one of the I2C buses is also available
> as an optional output/input.
>
> For sync/trigger outputs, there are three buffered 5V/16mA outputs that are
> all PWM capable.  The 5V PWM allows for driving external fans, which can be
> useful when using high power LEDs, especially since the driver can also
> monitor LED temperature.  The current sense voltage is also connected as an
> output, with a series 100 ohm resistor to protect against accidentally
> shorting the current sense voltage (which would be very bad).  This current
> sense output voltage is also connected to an analog pin on the Teensy,
> allowing internal monitoring of LED current as well.
>
> For user inputs, there is a toggle switch, four illuminated pushbuttons and
> a potentiometer.  The toggle switch is used to switch the driver between
> manual and sync mode.  The potentiometer allows for the LED intensity to be
> adjusted.  The pushbuttons will allow for switching between the four LED
> channels with the illumination indicating the active channel.  The
> illumination will also be used to warn of any fault status.
>
> Since the driver is designed to run at high powers, there is also
> integrated temperature monitoring, with one thermistor monitoring the
> mosfet temperature, and another thermistor monitoring the current sense
> resistor temperature.  This way, the driver can automatically turn off the
> LED current if the driver or LED starts to overheat, protecting both the
> driver and LED.  There is also a piezo transducer to generate an audible
> alarm in the event of an overheating fault.  The driver also is designed to
> be connected to a standard 4-pin 92 mm computer fan for cooling of the
> driver itself, and can control the fan speed using 5V PWM.
>
> If you have any further questions, please feel free to ask.
>
> Cheers,
>    Ben Smith
>
>
> On Wed, Nov 25, 2020 at 4:03 AM Gordon Scott <[hidden email]> wrote:
>
> > *****
> > To join, leave or search the confocal microscopy listserv, go to:
> > http://lists.umn.edu/cgi-bin/wa?A0=confocalmicroscopy
> > Post images on http://www.imgur.com and include the link in your
> posting.
> > *****
> >
> > Hi Benjamin,
> >
> > After the disgusting way my ex-employer treated me, I definitely should
> > be working on this.
> >
> > Please mail me links and/or data that I may have a look at the project
> > as a whole.
> >
> > Thanks.
> >
> > Kind regards,
> >
> >                           Gordon.
> >
> > On 24/11/2020 20:21, Benjamin Smith wrote:
> > > *****
> > > To join, leave or search the confocal microscopy listserv, go to:
> > > http://lists.umn.edu/cgi-bin/wa?A0=confocalmicroscopy
> > > Post images on http://www.imgur.com and include the link in your
> > posting.
> > > *****
> > >
> > > Hey Microscopists,
> > >
> > > I am currently working on designing the graphical user interface for an
> > > open-source high-speed LED driver, and was hoping to get some feedback
> on
> > > ideas for built-in syncing options.
> > >
> >
>
>
> --
> Benjamin E. Smith, Ph. D.
> Imaging Specialist, Vision Science
> University of California, Berkeley
> 195 Life Sciences Addition
> Berkeley, CA  94720-3200
> Tel  [phone]
> Fax [phone]
> e-mail: [hidden email]
>
> https://vision.berkeley.edu/faculty/core-grants-nei/core-grant-microscopic-imaging/
>

--
--
Zdenek Svindrych, Ph.D.
Research Scientist - Microscopy Imaging Specialist
Department of Biochemistry and Cell Biology
Geisel School of Medicine at Dartmouth

[Zdenek Svindrych-2]

*****
To join, leave or search the confocal microscopy listserv, go to:
http://lists.umn.edu/cgi-bin/wa?A0=confocalmicroscopy
Post images on http://www.imgur.com and include the link in your posting.
*****

Hi Ben,

really nice and capable GUI!
Just one thing in the Configure panel, the "Fan" section does not seem to
follow the logical order of the other sections (I'd expect a min-max pair
in each column, maybe you just swapped the labels).

And there could be a never ending discussion about the best interface...
I love serial (on old hardware), it always works, and if it does not, you
can hack it :-). But it becomes a problem when you already have half a
dozen serial connections in the setup already (real or virtual - over USB),
it's enough to lose track of what's what.
With a proprietary protocol you could take advantage of the board
capabilities (Teensy 3.6 supports USB 2.0 High Speed!), but it's a lot of
work (I never wrote a driver myself, libusb is a good option here) and
often buggy, and vendor lock-in, and so on.

Btw, my experience with USB is not great. Anytime a device stops
communicating (like a camera or so) I think of the Apollo mission - If they
relied on USB back then, they would not make it to the ramp, let alone to
the Moon...
One standard that does work well, though, is HID (I rarely have issues with
keyboards or mice), so that's what I would use for low speed communication
(some Andor laser boxes use this, too). And you don't have to worry about
the driver!

Good luck and thanks for sharing this open source project!

zdenek

On Tue, Nov 24, 2020 at 3:34 PM Benjamin Smith <[hidden email]>
wrote:

> *****
> To join, leave or search the confocal microscopy listserv, go to:
> http://lists.umn.edu/cgi-bin/wa?A0=confocalmicroscopy
> Post images on http://www.imgur.com and include the link in your posting.
> *****
>
> Hey Microscopists,
>
> I am currently working on designing the graphical user interface for an
> open-source high-speed LED driver, and was hoping to get some feedback on
> ideas for built-in syncing options.
>
> For reference, the driver itself has four LED channels, >3 MHz bandwidth,
> can drive up to four <1.5A LEDs or one <40A LED.  The on-board
> microcontroller is a Teensy 3.6.  This is also the current layout for the
> GUI:
>
> Main panel - https://bit.ly/3pWzqJi
> Configure panel - https://bit.ly/33gsxJf
> Calibration panel - https://bit.ly/3pZwXO7
> Staus: text - https://bit.ly/2UUIzno
> Status: graph - https://bit.ly/2UW2DWm
>
> These are the sync inputs I'm thinking of:
>
> *Confocal* - sync an LED to the scanning mirrors of a laser scanning
> confocal microscope
> - Analog (4 µs latency) - sync to the analog voltage driving the fast (x)
> mirror.
> - Digital (40 ns latency) - sync to a line clock output (ideal for resonant
> systems)
>
> *Digital* - sync to a digital input (such as a camera TTL output)
>
> *Analog*
> - Mirroring (5 us latency) - use the ADC to read an analog input, and then
> mirror that input onto the DAC controlling the driver.  This will allow for
> preserving programmed current limits and protect the driver from over/under
> voltages.
> - Direct (minimal latency) - directly port an input analog signal to the
> op-amp controlling the LED current.  Fastest possible drive speed, but will
> override programmed current limits (a warning window will definitely pop up
> before activating this mode).
>
> *Arbitrary wave generator (AWG)*
> - Internal memory - pre-load an arbitrary wave function onto theTeensy SD
> card or load over serial
> - Real-time serial - play an arbitrary wave function streamed in real-time
> over serial
>
> *Macro* (for LED channel sequencing, for-loops, etc.)
> - Dedicated Teensy function - program a dedicated custom function in the
> Teensy source code in C++ that is then called by the GUI.  This will allow
> for very low latency sync regimens
> - Serial through GUI - Write a sync macro in Python within the GUI itself,
> and the program will then coordinate the sync with the driver over serial.
> This will have higher latency (not yet tested but likely around10-100 us),
> but will allow much simpler coding of custom sync regimens.
>
> *FLIM?* - Given the LED driver's speed, would it also be worthwhile to add
> a FLIM mode?
>
> As this is a solo project, any feedback would be much appreciated.
>
> Cheers,
>    Ben Smith
>
> --
> Benjamin E. Smith, Ph. D.
> Imaging Specialist, Vision Science
> University of California, Berkeley
> 195 Life Sciences Addition
> Berkeley, CA  94720-3200
> Tel  [phone]
> Fax [phone]
> e-mail: [hidden email]
>
> https://vision.berkeley.edu/faculty/core-grants-nei/core-grant-microscopic-imaging/
>

--
--
Zdenek Svindrych, Ph.D.
Research Scientist - Microscopy Imaging Specialist
Department of Biochemistry and Cell Biology
Geisel School of Medicine at Dartmouth

[Benjamin Smith]

*****
To join, leave or search the confocal microscopy listserv, go to:
http://lists.umn.edu/cgi-bin/wa?A0=confocalmicroscopy
Post images on http://www.imgur.com and include the link in your posting.
*****

Hey Zdenek,

You are definitely right about the risk of not using interrupts.  For
reference, when the driver is in manual mode, or in confocal standby
(waiting for a scan to start) I use interrupts to check driver temperature,
send and receive serial information, etc., as like you said they are much
safer.

Unfortunately, the Teensy and Arduino have blanket enable and disable
interrupts.  Therefore, if you leave interrupts enabled, that also means
background system interrupts are also enabled, such as checking the serial
buffers, etc., which are cleared every 1 ms.  The time it takes to clear
these background interrupts can be up to 10 µs, which causes far too much
jitter in the LED timing resulting in sporadic streaks across your image on
a two-photon microscope when the LED accidentally remained on due to a
background interrupt being cleared at just the wrong time.  Additionally,
for analog syncs, there isn't an interrupt for a specific value on the ADC,
so monitoring an analog voltage has to be done with a while loop.

That said, there are ways to enable and disable specific interrupts on the
Teensy by directly toggling the ARM interrupt registers, but this can have
unexpected consequences unless you are certain what background processes
and timers are also connected to that register, and I'm not sure I'm ready
to play with that kind of fire just yet.

Therefore, for the most precise possible timing during the confocal syncs,
all interrupts are disabled close to when the sync event is about to
happen, and are then re-enabled after the LED flash to allow for serial
communication and other processes that rely on interrupts before the next
"wait for sync".

For the Arduino, the workaround for getting trapped in the "wait for sync"
loop was to have the loop check the state of the shutter.  This way when
the shutter was closed, then the code would safely exit the loop.  This has
worked pretty much without problem on the previous version of the driver
(which used an Arduino).  The added bonus is that thanks to
port manipulations and bit masks, the while loop only took two clock cycles
(125 ns), and so was sufficiently precise on our resonant systems.

For the Teensy, there is an additional layer of protection I am hoping to
try which is the interval timer.  Basically, have the while loop check both
the interval timer and shutter, with the interval timer providing a timeout
safeguard.  The catch is I still have to measure how much hysteresis I get
adding that additional check, because if it takes too many clock cycles,
then it wouldn't work well enough on a resonant system.  Here's hoping the
combination of the 180 MHz clock speed and 32-bit ALU in the Teensy make
the check sufficiently fast!

One other thing I should point out in defense of the Teensy is that all
pins on the Teensy are interrupt capable, it's just the jitter from
background system interrupts that cause issues.

tl;dr -
Arduinos and Teensies also have background interrupts that can screw up
processes that require precise timing.  The easiest way to remedy this is
to disable all interrupts when precise timing is needed, and then re-enable
them.  Therefore, I effectively use the scanning mirror itself as a sort of
interrupt timer, performing system checks between each mirror trigger
event.  To safely exit the sync loop, the loop also monitors the state of
the shutter to tell when a scan has stopped.

Thank you for the tip!
    Ben Smith



On Wed, Nov 25, 2020 at 6:17 PM Zdenek Svindrych <[hidden email]> wrote:

> *****
> To join, leave or search the confocal microscopy listserv, go to:
> http://lists.umn.edu/cgi-bin/wa?A0=confocalmicroscopy
> Post images on http://www.imgur.com and include the link in your posting.
> *****
>
> Hi Ben,
>
> impressive effort.
> But "...start watching for the next trigger event..." is the wrong
> approach. You should try to encode all the logic into the PWMs/timers (they
> are very flexible), or through interrupts (analog comparators or external
> comparators; any pin change can also raise an interrupt). Not sure how to
> implement this in Teensy-arduino (or whatever tools you're using), but
> assuming something's gonna happen in 1/16 ms is just waiting for a
> disaster. Use interrupts for sort-of-time-critical stuff, the rest (comm,
> ethernet, USB) is handled through FIFOs in it's own pace.
>
> *Disclaimer* The above is just a theory.
>
> Good luck!
> zdenek
>
> On Wed, Nov 25, 2020 at 2:50 PM Benjamin Smith <
> [hidden email]>
> wrote:
>
> > *****
> > To join, leave or search the confocal microscopy listserv, go to:
> > http://lists.umn.edu/cgi-bin/wa?A0=confocalmicroscopy
> > Post images on http://www.imgur.com and include the link in your
> posting.
> > *****
> >
> > Hey Anthony,
> >
> > I was initially thinking of TCP (hadn't heard of websockets though,
> thanks
> > for the tip), but the speed penalty for TCP was the biggest issue.  For
> > example, when synced to a 16 kHz resonant microscope, the microcontroller
> > only has about 20 µs to complete any task before it needs to start
> watching
> > for the next trigger event.  Therefore, any serial protocol needs to be
> > able to be broken up into a set of smaller subtasks where no single task
> > ever takes more than about 15 µs (to ensure a bit of a time buffer).  On
> > the Teensy, USB serial tasks can be broken into smaller subtasks such as
> by
> > loading only a few bytes of data into the USB buffer at a time.
> > Transmission of the USB buffer is executed by a separate chip, which then
> > frees up the MCU to do other tasks.  While I do lose the security of TCP,
> > the USB protocol still has CRC built into the protocol (learned this the
> > hard way), so I still get some degree of protection from data corruption.
> >  I also realized that I only need TCP level data security for things like
> > uploading configuration data to the driver (which is not time sensitive),
> > and that streaming data such as the status of the driver is not data
> > critical, as if the GUI receives a bad status packet, it will only be at
> > most a tenth of a second before it gets another status update.
> Therefore,
> > my idea was to just manually do a TCP style handshake for the
> > configuration, and a simple data stream for the status updates to the
> GUI.
> > That said, if you know of a <15 µs implementation of websockets on the
> > Teensy, I would definitely like to hear more about it.
> >
> > Thanks again for the tip,
> >    Ben Smith
> >
> >
> >
> > On Wed, Nov 25, 2020 at 4:15 AM Anthony Clearn <
> > [hidden email]> wrote:
> >
> > > *****
> > > To join, leave or search the confocal microscopy listserv, go to:
> > > http://lists.umn.edu/cgi-bin/wa?A0=confocalmicroscopy
> > > Post images on http://www.imgur.com and include the link in your
> > posting.
> > > *****
> > >
> > > It might be useful to consider websockets
> > >
> > >
> > >
> >
> https://diyprojects.io/websocket-communication-esp8266-arduino-python-test-ws4py-library-raspberry-pi/#.X75G5rOnxaQ
> > >
> > > hth,
> > > a.
> > >
> > >   1. Feedback on sync ideas for open-source LED driver
> > >
> > > ----------------------------------------------------------------------
> > >
> > > Date:    Tue, 24 Nov 2020 12:21:15 -0800
> > > From:    Benjamin Smith <[hidden email]>
> > > Subject: Feedback on sync ideas for open-source LED driver
> > >
> > > *****
> > > To join, leave or search the confocal microscopy listserv, go to:
> > > http://lists.umn.edu/cgi-bin/wa?A0=confocalmicroscopy
> > > Post images on http://www.imgur.com and include the link in your
> > posting.
> > > *****
> > >
> > > Hey Microscopists,
> > >
> > > I am currently working on designing the graphical user interface for an
> > > open-source high-speed LED driver, and was hoping to get some feedback
> on
> > > ideas for built-in syncing options.
> > >
> > > For reference, the driver itself has four LED channels, >3 MHz
> bandwidth,
> > > can drive up to four <1.5A LEDs or one <40A LED.  The on-board
> > > microcontroller is a Teensy 3.6.  This is also the current layout for
> the
> > > GUI:
> > >
> > > Main panel -
> > >
> >
> https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fbit.ly%2f3pWzqJi&c=E,1,Zc6gSDb3ppvZRQ30KRTB7JqvSYW0izEnURc1eu8mJ1oRAyNxk_vnK4GlivjqypskwtAH-CxVNhlP8mI59qK09wb942Io5h-CLC_bB5GyEVOlS8ivcykMXTIp0w,,&typo=1
> > > Configure panel -
> > >
> >
> https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fbit.ly%2f33gsxJf&c=E,1,pX40f1cJ74ZvvyGRZ3AWXOwjos774BalB4Tm-zYyx4FAcU1bzfaB83Rh38GnhV_q5a_GSzQHKCo1K8FbcufTohMPuQ_9IlLNaYKkiD2NgROGzt-Edc0,&typo=1
> > > Calibration panel -
> > >
> >
> https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fbit.ly%2f3pZwXO7&c=E,1,3odXdKCGf7ohqKBXzq-x6hBDALG7uq5SL8xqdYT3N4wOGvmszw9qyGVJA_IggvNqOoTDEkFCWo0AKrD58-RlUwr64DsmuqcnZsmkwBSceucsBORU&typo=1
> > > Staus: text -
> > >
> >
> https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fbit.ly%2f2UUIzno&c=E,1,RFM-lkiKvOCDDNAYNssz4mFD8HtXoSSKUvlsCFas4k1vN2YDSreBVi_UW4-GOPmAHPCyVgmPbPbA5-qj0lTZAtIQdTirn60lsRvJz2PzJT8,&typo=1
> > > Status: graph -
> > >
> >
> https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fbit.ly%2f2UW2DWm&c=E,1,xY0ivl0orJzcZNdd3_x6YoVH5VZXQyMoIIOyEembpq5M8Kf99sxSTt9lMKCDw9DZ4yAFOHxqW2GIDJifOnbje0tcZ8uYmNz17Wm98-X1iuk8UEs52EZO2A,,&typo=1
> > >
> > > These are the sync inputs I'm thinking of:
> > >
> > > *Confocal* - sync an LED to the scanning mirrors of a laser scanning
> > > confocal microscope
> > > - Analog (4 µs latency) - sync to the analog voltage driving the fast
> (x)
> > > mirror.
> > > - Digital (40 ns latency) - sync to a line clock output (ideal for
> > resonant
> > > systems)
> > >
> > > *Digital* - sync to a digital input (such as a camera TTL output)
> > >
> > > *Analog*
> > > - Mirroring (5 us latency) - use the ADC to read an analog input, and
> > then
> > > mirror that input onto the DAC controlling the driver.  This will allow
> > for
> > > preserving programmed current limits and protect the driver from
> > over/under
> > > voltages.
> > > - Direct (minimal latency) - directly port an input analog signal to
> the
> > > op-amp controlling the LED current.  Fastest possible drive speed, but
> > will
> > > override programmed current limits (a warning window will definitely
> pop
> > up
> > > before activating this mode).
> > >
> > > *Arbitrary wave generator (AWG)*
> > > - Internal memory - pre-load an arbitrary wave function onto theTeensy
> SD
> > > card or load over serial
> > > - Real-time serial - play an arbitrary wave function streamed in
> > real-time
> > > over serial
> > >
> > > *Macro* (for LED channel sequencing, for-loops, etc.)
> > > - Dedicated Teensy function - program a dedicated custom function in
> the
> > > Teensy source code in C++ that is then called by the GUI.  This will
> > allow
> > > for very low latency sync regimens
> > > - Serial through GUI - Write a sync macro in Python within the GUI
> > itself,
> > > and the program will then coordinate the sync with the driver over
> > serial.
> > > This will have higher latency (not yet tested but likely around10-100
> > us),
> > > but will allow much simpler coding of custom sync regimens.
> > >
> > > *FLIM?* - Given the LED driver's speed, would it also be worthwhile to
> > add
> > > a FLIM mode?
> > >
> > > As this is a solo project, any feedback would be much appreciated.
> > >
> > > Cheers,
> > >    Ben Smith
> > >
> >
> >
> > --
> > Benjamin E. Smith, Ph. D.
> > Imaging Specialist, Vision Science
> > University of California, Berkeley
> > 195 Life Sciences Addition
> > Berkeley, CA  94720-3200
> > Tel  [phone]
> > Fax [phone]
> > e-mail: [hidden email]
> >
> >
> https://vision.berkeley.edu/faculty/core-grants-nei/core-grant-microscopic-imaging/
> >
>
>
> --
> --
> Zdenek Svindrych, Ph.D.
> Research Scientist - Microscopy Imaging Specialist
> Department of Biochemistry and Cell Biology
> Geisel School of Medicine at Dartmouth
>

--
Benjamin E. Smith, Ph. D.
Imaging Specialist, Vision Science
University of California, Berkeley
195 Life Sciences Addition
Berkeley, CA  94720-3200
Tel  [phone]
Fax [phone]
e-mail: [hidden email]
https://vision.berkeley.edu/faculty/core-grants-nei/core-grant-microscopic-imaging/

[Benjamin Smith]

*****
To join, leave or search the confocal microscopy listserv, go to:
http://lists.umn.edu/cgi-bin/wa?A0=confocalmicroscopy
Post images on http://www.imgur.com and include the link in your posting.
*****

Hey Zdenek,

Good catch on the fan GUI, I completely missed that, thanks!  One of those
classic cases where you proofread past your own typos.

And Yes, the USB 2.0 high speed is absolutely amazing!  For example, to
calibrate the LED driver in the GUI, I have the ADC stream a 1600 sample
recording of the driver current to DMA, allowing for 1.1 megasamples per
second without locking up the microcontroller - speaking of the awesomeness
of interrupts ;).  I can then directly push the DMA buffer onto the serial
buffer which clears at 12 Mb/s, with the end result being able to record
1600 16-bit values in just a couple of milliseconds, and then send all 3200
bytes of information in just another couple of milliseconds.  This allows
for having a pretty decent looking live oscilloscope in the GUI with a 50
Hz refresh rate: https://bit.ly/3nUGDI0

One trick I learned recently for this project that has been a total game
changer, is not only how to query the USB host controller for a specific
PID and VID, but on the Teensy you can actually set the serial number in
code.  This means that you can program the Teensy with a unique serial
number, and then search the USB host controller for any device with the
correct PID, VID, and serial number.  This way, you never have to send out
any "magic bytes" to sniff out your device on the COM port, so cool!  The
only catch is that the serial number is also how the USB host controller
knows that you are reconnecting the same device, and therefore will give it
the same COM port as before.  Therefore, having two devices with the same
serial number, or worse no serial number can cause issues.

Therefore, the GUI serial initialization involves searching the USB host
controller for any connected Teensies (based on the PID and VID).  It then
checks to see if any have a custom serial number.  If so, it lists all
available drivers with the same root serial number "MHZ_LEDnn".  If instead
it finds Teensies but doesn't find a unique serial number, it assumes that
the custom serial number feature was not used, and then does the classic
magic byte handshake to find the LED drivers instead, but at least it is
now only spamming Teensies rather than all possible COM ports.  I have no
idea why more GUIs don't use this feature, it is so much faster and safer
than COM port sniffing.

Thanks again for your help and insights,
   Ben Smith

On Wed, Nov 25, 2020 at 8:38 PM Zdenek Svindrych <[hidden email]> wrote:

> *****
> To join, leave or search the confocal microscopy listserv, go to:
> http://lists.umn.edu/cgi-bin/wa?A0=confocalmicroscopy
> Post images on http://www.imgur.com and include the link in your posting.
> *****
>
> Hi Ben,
>
> really nice and capable GUI!
> Just one thing in the Configure panel, the "Fan" section does not seem to
> follow the logical order of the other sections (I'd expect a min-max pair
> in each column, maybe you just swapped the labels).
>
> And there could be a never ending discussion about the best interface...
> I love serial (on old hardware), it always works, and if it does not, you
> can hack it :-). But it becomes a problem when you already have half a
> dozen serial connections in the setup already (real or virtual - over USB),
> it's enough to lose track of what's what.
> With a proprietary protocol you could take advantage of the board
> capabilities (Teensy 3.6 supports USB 2.0 High Speed!), but it's a lot of
> work (I never wrote a driver myself, libusb is a good option here) and
> often buggy, and vendor lock-in, and so on.
>
> Btw, my experience with USB is not great. Anytime a device stops
> communicating (like a camera or so) I think of the Apollo mission - If they
> relied on USB back then, they would not make it to the ramp, let alone to
> the Moon...
> One standard that does work well, though, is HID (I rarely have issues with
> keyboards or mice), so that's what I would use for low speed communication
> (some Andor laser boxes use this, too). And you don't have to worry about
> the driver!
>
> Good luck and thanks for sharing this open source project!
>
> zdenek
>
> On Tue, Nov 24, 2020 at 3:34 PM Benjamin Smith <
> [hidden email]>
> wrote:
>
> > *****
> > To join, leave or search the confocal microscopy listserv, go to:
> > http://lists.umn.edu/cgi-bin/wa?A0=confocalmicroscopy
> > Post images on http://www.imgur.com and include the link in your
> posting.
> > *****
> >
> > Hey Microscopists,
> >
> > I am currently working on designing the graphical user interface for an
> > open-source high-speed LED driver, and was hoping to get some feedback on
> > ideas for built-in syncing options.
> >
> > For reference, the driver itself has four LED channels, >3 MHz bandwidth,
> > can drive up to four <1.5A LEDs or one <40A LED.  The on-board
> > microcontroller is a Teensy 3.6.  This is also the current layout for the
> > GUI:
> >
> > Main panel - https://bit.ly/3pWzqJi
> > Configure panel - https://bit.ly/33gsxJf
> > Calibration panel - https://bit.ly/3pZwXO7
> > Staus: text - https://bit.ly/2UUIzno
> > Status: graph - https://bit.ly/2UW2DWm
> >
> > These are the sync inputs I'm thinking of:
> >
> > *Confocal* - sync an LED to the scanning mirrors of a laser scanning
> > confocal microscope
> > - Analog (4 µs latency) - sync to the analog voltage driving the fast (x)
> > mirror.
> > - Digital (40 ns latency) - sync to a line clock output (ideal for
> resonant
> > systems)
> >
> > *Digital* - sync to a digital input (such as a camera TTL output)
> >
> > *Analog*
> > - Mirroring (5 us latency) - use the ADC to read an analog input, and
> then
> > mirror that input onto the DAC controlling the driver.  This will allow
> for
> > preserving programmed current limits and protect the driver from
> over/under
> > voltages.
> > - Direct (minimal latency) - directly port an input analog signal to the
> > op-amp controlling the LED current.  Fastest possible drive speed, but
> will
> > override programmed current limits (a warning window will definitely pop
> up
> > before activating this mode).
> >
> > *Arbitrary wave generator (AWG)*
> > - Internal memory - pre-load an arbitrary wave function onto theTeensy SD
> > card or load over serial
> > - Real-time serial - play an arbitrary wave function streamed in
> real-time
> > over serial
> >
> > *Macro* (for LED channel sequencing, for-loops, etc.)
> > - Dedicated Teensy function - program a dedicated custom function in the
> > Teensy source code in C++ that is then called by the GUI.  This will
> allow
> > for very low latency sync regimens
> > - Serial through GUI - Write a sync macro in Python within the GUI
> itself,
> > and the program will then coordinate the sync with the driver over
> serial.
> > This will have higher latency (not yet tested but likely around10-100
> us),
> > but will allow much simpler coding of custom sync regimens.
> >
> > *FLIM?* - Given the LED driver's speed, would it also be worthwhile to
> add
> > a FLIM mode?
> >
> > As this is a solo project, any feedback would be much appreciated.
> >
> > Cheers,
> >    Ben Smith
> >
> > --
> > Benjamin E. Smith, Ph. D.
> > Imaging Specialist, Vision Science
> > University of California, Berkeley
> > 195 Life Sciences Addition
> > Berkeley, CA  94720-3200
> > Tel  [phone]
> > Fax [phone]
> > e-mail: [hidden email]
> >
> >
> https://vision.berkeley.edu/faculty/core-grants-nei/core-grant-microscopic-imaging/
> >
>
>
> --
> --
> Zdenek Svindrych, Ph.D.
> Research Scientist - Microscopy Imaging Specialist
> Department of Biochemistry and Cell Biology
> Geisel School of Medicine at Dartmouth
>

--
Benjamin E. Smith, Ph. D.
Imaging Specialist, Vision Science
University of California, Berkeley
195 Life Sciences Addition
Berkeley, CA  94720-3200
Tel  [phone]
Fax [phone]
e-mail: [hidden email]
https://vision.berkeley.edu/faculty/core-grants-nei/core-grant-microscopic-imaging/

[Gordon Scott-3]

*****
To join, leave or search the confocal microscopy listserv, go to:
http://lists.umn.edu/cgi-bin/wa?A0=confocalmicroscopy
Post images on http://www.imgur.com and include the link in your posting.
*****

Hi all,

Specifically on syncing to precise triggers, my first product used an
internal queue of events with an option to wait for an external or
internal event before proceeding, e.g., an TTL interrupt or an internal
timer.  I did that as we then were asked to keep what we were doing a
secret, so we weren't allowed to discuss ideas with any end users.  The
queue turned out 'too clever' for most users and the inherent delay of
putting things into a queue and taking them out for use slowed the
product when "driven directly" via TCP or USB.  I later did a simpler
sequence of actions to be stepped simply by a TTL stimulus, which was
better accepted.
That said, I don't honestly know whether that 'too clever' was a
perception of customers or sales people. A TTL out can make the LED the
centre of its timing universe if the other kit will play ball.

Because of its time-slotting, USB always(?) has an inherent delay of
around a millisecond. It does, though, have a good sustained throughput,
allowing quasi-analogue control into many kiloHertz.

Internet Protocol (IP) can have less delay, but can also have much more.
IP does, though, offer control around and potentially off of the planet
and can be great for diagnostics.

If one needs guaranteed sub-millisecond response, one probably has to
use a hardware trigger like TTL or similar.

Prior to me work on light sources, I would aim to include IP if I could,
but then I worked in the communications industry and most comms people
are very pro comms ... of course.  It came as a shock with the light
sources to have people say, literally or in effect, "we don't want to
use the network, because IT always want to take control of our kit". I
added USB.

I wonder if that is still an issue. Quite likely.


On 26/11/2020 03:59, Zdenek Svindrych wrote:
>   I'm not a big fan of big LEDs and I think most things can be
> achieved with 1mm x 1mm LEDs

Indeed. Big LEDs can be counterproductive.  I'm no expect on confocal,
but I believe the ideal light source would be a perfect point and we
should aim as close to that as we can.  For other microscopy techniques
that may be different.

On 26/11/2020 03:59, Zdenek Svindrych wrote:
> .. but a real pro would use current
> mode PWM (to set the LED current) and shunt FET (to turn the led on/off
> quickly).

One needs to weigh up pros and cons for that ... speed against
ripple-current for the LED, and against dissipation in the module. I
believe ripple current can potentially be an image killer, causing
banding in the images.



On 26/11/2020 05:21, Benjamin Smith wrote:
> One other thing I should point out in defense of the Teensy is that all
> pins on the Teensy are interrupt capable, it's just the jitter from
> background system interrupts that cause issues.

The ARM processors normally also a high degree of control of the
priorities of interrupts, so it should be feasible to push system
interrupts down the priority list.


On 26/11/2020 05:49, Benjamin Smith wrote:
> The
> only catch is that the serial number is also how the USB host controller
> knows that you are reconnecting the same device, and therefore will give it
> the same COM port as before.  Therefore, having two devices with the same
> serial number, or worse no serial number can cause issues.

I used serial 0000 as the 'non-serial' value and it seemed to work well.
IIRC that's he convention.  That also avoids a tester ending up with
hundreds of serial numbers and hundreds of COM ports in their Windows PC :-)



On the hardware:

Initially I was concerned that the current sense resistance appears to
be 1.25 Ohms, whilst you're talking about 30A LEDs, but I believe you
expect different resistors for high current LEDs.  I used a very much
smaller value, but that does create a potential ground-bounce issue,
which demands the OPA feedback is taken from right at the sense resistor.

I suspect(!) that the OPA/MOSFET can be universally compensated,
removing the need for the trimmers, but I'd need some time to explore that.

Beyond that, for the present, I'll be looking deeper into what's there. 
Someone mentioned using buck regulators to drop input voltage to more
suitable for LEDs, which works extremely well.  It's also pretty common
practice for supplies for PC CPUs to have their voltage set appropriate
for the device, so I think I have no risk in saying that a means to
manage an external buck regulator, perhaps as an additional module, may
well be useful.  Certainly one of my aims with the products I designed
was to try to be as energy efficient as was reasonable.  That's less
easy in an OpenSource modular context, but still a worthy aim.

Kind regards,
                       Gordon.

[Anthony Clearn]

*****
To join, leave or search the confocal microscopy listserv, go to:
http://lists.umn.edu/cgi-bin/wa?A0=confocalmicroscopy
Post images on http://www.imgur.com and include the link in your posting.
*****


Hi Ben,

there may be some info here.

 https://github.com/facundofarias/awesome-websockets

                                                  A curated list of WebSockets related principles and technologies


Other fields may have similar issues/solutions.

https://www.google.com/search?q=cern+websockets+%22ns%22



Regards,
Anthony.

________________________________

On Wed, Nov 25, 2020 at 2:50 PM Benjamin Smith <[hidden email]>
wrote:

> Hey Anthony,
>
> I was initially thinking of TCP (hadn't heard of websockets though, thanks
> for the tip), but the speed penalty for TCP was the biggest issue.  For
> example, when synced to a 16 kHz resonant microscope, the microcontroller
> only has about 20 µs to complete any task before it needs to start watching
> for the next trigger event.  Therefore, any serial protocol needs to be
> able to be broken up into a set of smaller subtasks where no single task
> ever takes more than about 15 µs (to ensure a bit of a time buffer).  On
> the Teensy, USB serial tasks can be broken into smaller subtasks such as by
> loading only a few bytes of data into the USB buffer at a time.
> Transmission of the USB buffer is executed by a separate chip, which then
> frees up the MCU to do other tasks.  While I do lose the security of TCP,
> the USB protocol still has CRC built into the protocol (learned this the
> hard way), so I still get some degree of protection from data corruption.
>  I also realized that I only need TCP level data security for things like
> uploading configuration data to the driver (which is not time sensitive),
> and that streaming data such as the status of the driver is not data
> critical, as if the GUI receives a bad status packet, it will only be at
> most a tenth of a second before it gets another status update.  Therefore,
> my idea was to just manually do a TCP style handshake for the
> configuration, and a simple data stream for the status updates to the GUI.
> That said, if you know of a <15 µs implementation of websockets on the
> Teensy, I would definitely like to hear more about it.
>
> Thanks again for the tip,
>    Ben Smith
>
>*********************

[Benjamin Smith]

*****
To join, leave or search the confocal microscopy listserv, go to:
http://lists.umn.edu/cgi-bin/wa?A0=confocalmicroscopy
Post images on http://www.imgur.com and include the link in your posting.
*****

In regards to the high current LEDs, these are the ones that we use for
optogenetics: https://bit.ly/2Jhnukm

They are absolutely amazing, with the blue one putting out almost 11W of
optical power at 20A with just a 3 mm x 3 mm die.  Here is an image I took
of the 385 nm LED running at 18A - it is so bright the induced
phosphorescence on the nearby paper saturated the camera:
https://bit.ly/367CD0I
To keep these LEDs nice and cool, I just bolted them to a Noctua CPU cooler
which is WAY overkill: https://bit.ly/3fGOiaa
Here is a full setup installed on a microscope (in this case being combined
with an LLG from a xenon arc lamp to illuminate a DMD):
https://bit.ly/39i8wFS

----

In regards to dropping the LED supply voltage, in the original LED driver
and the current version I did this the other way around, where the power
supply voltage is the LED voltage, and this then gets shifted for the
op-amp and peripherals.  You want to do it this way, as the LED draws far
more current than the driver, so it is a lot easier to shift the driver
voltage than the LED voltage.  On the original driver, I used two hand
built SEPIC converters to create the +12V and -5V rails, which were then
heavily filtered and then shifted using LDOs to +10V and -1.8V for the
op-amp, and the -5V also powered an internal fan, and the +12V powered the
Arduino.  This worked fine but added a LOT of unique parts to the build,
making just placing the components on the board take over an hour.  With
the new driver, I fixed this by assuming the driver will normally have
a +12V input for 1A LEDs, and therefore there is a jumper that allows
the +12V to also power the driver directly.  There is then a discrete
module that takes the +12V and generates +5V and -5V.  The +5V powers the
5V TTL buffer and the Teensy, and the +12V and -5V go through an RC filter
and then a pair of LDOs to provide clean +10V and -1.8V for the op-amp.  In
the case for high current or high voltage LEDs, the jumper can be replaced
with a three pin header, which allows you to connect a +12V boost or +12V
buck converter.

Another issue with dropping the LED supply voltage is that you take a
pretty big speed penalty.  This is because the inductance of the wires
going to the LED is the primary limiter to the slew rate at these speeds.
One way around this is to use magnet wire twisted pairs to get the
inductance as low as possible: https://bit.ly/2JjikEt
However, even still the inductance is the rate limiting factor, so you want
as much extra voltage as you can get to spin-up the inductance as fast as
possible and turn the LED on.  For example here is an example showing that
with 9V extra voltage (12V supply driving a 3V LED), the slew rate from 0 -
1A is just 200 ns.  https://bit.ly/2JjiEmF
However, as you noticed, you can't have nearly as much excess voltage in a
high current application, and so you can see with the 20A LED the slew rate
drops to 30 µs: https://bit.ly/2JbgbLy

This was part of the motivation of switching from using copper pads and
thermal vias on FR4 to dump heat to going with a MCPCB.  The hope is this
will allow for at least a hundred millivolts overhead in high current
applications, which would dramatically increase the slew rate.  For
example, here is the same 20A LED being driven at 16A and that extra 100mV
cut the slew rate in half to 16 µs:  https://bit.ly/33i3cyE, and driving
the LED at 4A (adding a just a few more 100 mV  of oomph) got the slew rate
down to 1.5 µs: https://bit.ly/3mbcDHs

----

In regards to high current LED PWM vs current control, the code used for
the high current drivers is definitely different from the low current
drivers.  For the low current drivers, the full analog and PWM range is
available to get a full 2D space to adjust the intensity across over 8
orders of magnitude.  These drivers are also just convectively cooled with
no issues.  For the high current LEDs, you really can't have current
control in the midrange of the LED output, or else you wind up with a LOT
of watts across the poor MOSFET.  As a result, for the high current
drivers, the current control works as a step function, where the intensity
is primarily controlled with PWM, and then we have a high and low setting,
where high is 100% current output (meaning only a couple 100 mV across the
MOSFET), and low is a 10% current setting, which still gives us the >8
orders of magnitude intensity control.  This jumps over the dangerous
middle region of the current control, keeping the LED driver nice and
cool.  That said, in addition to the much better cooling, the MOSFET I
chose can handle up to 150°C with a very gradual derating curve, and the
resistors can handle 175°C and 45W also with a gradual derating curve.
That said, a lot of nearby parts can only handle up to 85°C, so the MOSFET
and resistor rating are more used for safety margins than anything I hope
to actually rely on.

On a side note, I regularly have to point out to users of these drivers
that they want to use PWM if at all possible, because PWM is nearly
perfectly linear in its response, while LED current is very much non-linear
(with some LEDs being worse than others).  The peak wavelength of an LED
also technically shifts with current, but if you look at the datasheets for
any modern LED those shifts tend to be at most a few nm which is perfectly
fine for most applications.

----

In regards to the op-amp compensation, adjustable compensation is the only
way I found to get the highest speed possible.  For example, if you put the
unitary gain equivalent op-amp (the LT6200) into the spice simulation, the
LED slews much slower.  This makes sense as a unitary gain op-amp has so
much internal compensation that nearly any phase delay will still not
destabilize the op-amp.  However, the LEDs are nowhere near unitary gain,
and so by having an adjustable compensation, this allows for getting every
last drop of speed you want.  The other reason for it being adjustable, is
that the two biggest factors on the amount of compensation needed are the
maximum current of the driver, and the type of cable going to the LED.
Therefore, you could hold the compensation fixed for a specific setup, but
then one would need to know exactly the wire type and LED current and then
use a LUT to find the right compensation.  Conversely, the adjustment is
very simple, and I also integrated it into the GUI for those without an
oscilloscope.  Basically, you turn down both trim-pots until the driver
begins to oscillate.  You then increase the trimpots just until the
oscillation stops, and this is the optimum compensation for high speed.
The other advantage of the adjustable compensation is that you can also
turn it to 0 ohms, and then find the resonant frequency of the driver,
which will allow you to drive an LED with a 4-10 MHz sine wave depending on
the setup, which would be potentially useful for things like FLIM.

----

In regards to MOSFET types, you hit a key design choice I made with the
current driver.  In the previous driver, I found a perfect MOSFET, but it
had a custom footprint meaning that you could only use that MOSFET.  With
the new design, I deliberately choose a DPAK power mosfet.  This way, more
advanced users can easily change out the mosfet for their particular
application.  For example, if you want a driver to go as fast as possible
at a low current (1A or below), you could swap out the mosfet for much
faster ones.  Particularly there are four key factors for speed: 1) the
on/off time of the mosfet, 2) the gate charge, 3) the gate resistance, and
4) the response curve.  Most of these are self explanatory except maybe the
response curve.  To go as fast as possible, you ideally want a MOSFET with
a flat response curve (basically a mosfet that acts more like a jfet).  The
flatter the curve the less op-amp compensation you need, as the opamp has a
wider range of voltages to play with to stabilize the current.  Twitchy
mosfets need a lot of compensation, as just a small gate voltage overshoot
allows exponentially more current and therefore can trigger
an oscillation.   Therefore, the best mosfet would have a short on-off
time, low gate resistance, low gate charge, and a flat response curve.
Unfortunately, most power mosfets are designed to be "twitchty" as they are
most often used as motor drivers, and therefore the twitchier the better
for that application.

----

In regards to better efficiency, there are two clever solutions, one of
which is commercially available.  The commercially available one is an LED
driver IC that works as a SEPIC converter to drive the LED efficiently, but
on top of that when the PWM signal goes low, the SEPIC converter diverts
the residual inductor current to charge an output cap before turning off.
This way, when the PWM goes high again the cap is discharged through the
LED to start turning it on while the SEPIC converter spins back up again.
The catch is that the driver needs at least a few clock cycles to spin back
up, so the fastest one I could find was rated to 20 kHz PWM which was far
too slow for our applications, and especially useless with a resonant scope
where even with a 8 kHz mirror, the LED can only be on for 18 µs at the
very most.  A really cool approach used in high speed telecommunications is
to have a high voltage charge pump turn the LED on (similar to
other highspeed protocols like PCI).  Basically, when the circuit wants to
turn the LED on, the circuit first applies the high voltage supply to the
LED to not only overcome any inductance, but also to get the charge
carriers into the depletion region as fast as possible.  The driver then
switches to a low voltage supply to maintain the LED current until the LED
is turned off.  These drivers can turn LEDs on and off in under a
nanosecond, but the catch is that the driver has to be perfectly tuned to
each LED as even differences in the die composition change the needed
parameters, and you need a controller IC capable of sub-nanosecond
precision.  As such, there are no commercially available solutions (outside
of telecom drivers which are extremely expensive and highly specialized),
and academic papers made it clear setting these up is fairly non-trivial.
Cool trick though.

Thanks again for all the insights and ideas. If you can't tell, it is so
nice to finally have people to talk about all of this.
     Ben Smith


On Thu, Nov 26, 2020 at 4:56 AM Gordon Scott <[hidden email]> wrote:

> *****
> To join, leave or search the confocal microscopy listserv, go to:
> http://lists.umn.edu/cgi-bin/wa?A0=confocalmicroscopy
> Post images on http://www.imgur.com and include the link in your posting.
> *****
>
> Hi all,
>
> Specifically on syncing to precise triggers, my first product used an
> internal queue of events with an option to wait for an external or
> internal event before proceeding, e.g., an TTL interrupt or an internal
> timer.  I did that as we then were asked to keep what we were doing a
> secret, so we weren't allowed to discuss ideas with any end users.  The
> queue turned out 'too clever' for most users and the inherent delay of
> putting things into a queue and taking them out for use slowed the
> product when "driven directly" via TCP or USB.  I later did a simpler
> sequence of actions to be stepped simply by a TTL stimulus, which was
> better accepted.
> That said, I don't honestly know whether that 'too clever' was a
> perception of customers or sales people. A TTL out can make the LED the
> centre of its timing universe if the other kit will play ball.
>
> Because of its time-slotting, USB always(?) has an inherent delay of
> around a millisecond. It does, though, have a good sustained throughput,
> allowing quasi-analogue control into many kiloHertz.
>
> Internet Protocol (IP) can have less delay, but can also have much more.
> IP does, though, offer control around and potentially off of the planet
> and can be great for diagnostics.
>
> If one needs guaranteed sub-millisecond response, one probably has to
> use a hardware trigger like TTL or similar.
>
> Prior to me work on light sources, I would aim to include IP if I could,
> but then I worked in the communications industry and most comms people
> are very pro comms ... of course.  It came as a shock with the light
> sources to have people say, literally or in effect, "we don't want to
> use the network, because IT always want to take control of our kit". I
> added USB.
>
> I wonder if that is still an issue. Quite likely.
>
>
> On 26/11/2020 03:59, Zdenek Svindrych wrote:
> >   I'm not a big fan of big LEDs and I think most things can be
> > achieved with 1mm x 1mm LEDs
>
> Indeed. Big LEDs can be counterproductive.  I'm no expect on confocal,
> but I believe the ideal light source would be a perfect point and we
> should aim as close to that as we can.  For other microscopy techniques
> that may be different.
>
> On 26/11/2020 03:59, Zdenek Svindrych wrote:
> > .. but a real pro would use current
> > mode PWM (to set the LED current) and shunt FET (to turn the led on/off
> > quickly).
>
> One needs to weigh up pros and cons for that ... speed against
> ripple-current for the LED, and against dissipation in the module. I
> believe ripple current can potentially be an image killer, causing
> banding in the images.
>
>
>
> On 26/11/2020 05:21, Benjamin Smith wrote:
> > One other thing I should point out in defense of the Teensy is that all
> > pins on the Teensy are interrupt capable, it's just the jitter from
> > background system interrupts that cause issues.
>
> The ARM processors normally also a high degree of control of the
> priorities of interrupts, so it should be feasible to push system
> interrupts down the priority list.
>
>
> On 26/11/2020 05:49, Benjamin Smith wrote:
> > The
> > only catch is that the serial number is also how the USB host controller
> > knows that you are reconnecting the same device, and therefore will give
> it
> > the same COM port as before.  Therefore, having two devices with the same
> > serial number, or worse no serial number can cause issues.
>
> I used serial 0000 as the 'non-serial' value and it seemed to work well.
> IIRC that's he convention.  That also avoids a tester ending up with
> hundreds of serial numbers and hundreds of COM ports in their Windows PC
> :-)
>
>
>
> On the hardware:
>
> Initially I was concerned that the current sense resistance appears to
> be 1.25 Ohms, whilst you're talking about 30A LEDs, but I believe you
> expect different resistors for high current LEDs.  I used a very much
> smaller value, but that does create a potential ground-bounce issue,
> which demands the OPA feedback is taken from right at the sense resistor.
>
> I suspect(!) that the OPA/MOSFET can be universally compensated,
> removing the need for the trimmers, but I'd need some time to explore that.
>
> Beyond that, for the present, I'll be looking deeper into what's there.
> Someone mentioned using buck regulators to drop input voltage to more
> suitable for LEDs, which works extremely well.  It's also pretty common
> practice for supplies for PC CPUs to have their voltage set appropriate
> for the device, so I think I have no risk in saying that a means to
> manage an external buck regulator, perhaps as an additional module, may
> well be useful.  Certainly one of my aims with the products I designed
> was to try to be as energy efficient as was reasonable.  That's less
> easy in an OpenSource modular context, but still a worthy aim.
>
> Kind regards,
>                        Gordon.
>

--
Benjamin E. Smith, Ph. D.
Imaging Specialist, Vision Science
University of California, Berkeley
195 Life Sciences Addition
Berkeley, CA  94720-3200
Tel  [phone]
Fax [phone]
e-mail: [hidden email]
https://vision.berkeley.edu/faculty/core-grants-nei/core-grant-microscopic-imaging/

[Gordon Scott-3]

*****
To join, leave or search the confocal microscopy listserv, go to:
http://lists.umn.edu/cgi-bin/wa?A0=confocalmicroscopy
Post images on http://www.imgur.com and include the link in your posting.
*****

Hi Ben, all

On 26/11/2020 21:41, Benjamin Smith wrote:
> Another issue with dropping the LED supply voltage is that you take a
> pretty big speed penalty.  This is because the inductance of the wires
> going to the LED is the primary limiter to the slew rate at these speeds.


I was able to use quite short cables as the LEDs were usually in the
main unit and the distance to the microscope was covered using light
guides.  That also has benefits when using some of the microscopy
techniques involving small electric/magnetic fields.


In my setups, the speed was constrained more by the OpAmp's ability to
drive the MOSFET's gate charge  My speeds were also significantly lower
at 300kHz maximum.  As you mention, very short pulses are probably best
done in other ways ... in those cases, often one wants simply to deliver
a 'package' of light, with only a limited concern of the shape of the
pulse, provided it's short.


You don't say where your waveforms were measured. The scale suggests a
55V swing, which I presume is not correct.

At the final output, I generally measured the voltage across the sense
resistor, rather than elsewhere, as the voltages around the drain and
LED itself have significantly amplified error components due to the high
output impedance of the current sink. For an even more 'real' indicative
view of the light output waveform, I would use a photodiode in a
horribly hacked-together setup.


I fully understand your choice of a DPAK package, though as you allude,
their performance tends to be a bit 'clunky' in comparison with other
devices, but there's a huge range to choose from.  I rather suspect the
physical characteristics of the package itself are a limiting factor.


KInd regards,

                           Gordon.

[Benjamin Smith]

*****
To join, leave or search the confocal microscopy listserv, go to:
http://lists.umn.edu/cgi-bin/wa?A0=confocalmicroscopy
Post images on http://www.imgur.com and include the link in your posting.
*****

Yeah, once I posted that email, I realized in hindsight that those
oscilloscope plots needed a bit more clarification.  In those plots, the
driving signal is the top plot, and the current response is the bottom
plot.  The scope is an older scope, and it is a bit of a pain to switch the
units from 10x to 1x, so I've just gotten used to just dividing the values
by 10 in my head when using a 1x probe.  As such, the 1A driver had a 5 Ohm
current sense resistor, and so a 5V output (50V on the oscilloscope)
corresponded to a 1A current.  The 20A driver had a 50 mOhm current sense
resistor, so a 20A current corresponds to a 1V output (10V on the
oscilloscope).  These voltages were all measured directly across the
current sense resistor.  One key difference with the new driver is I put a
200 ohm resistor in series with the output voltage.  This is for two
reasons: 1) if a user accidentally shorts the current sense voltage, then
the op-amp will fully close the MOSFET which will instantly destroy the
LED, and 2) the Teensy is also connected to the current sense voltage, so
if the Teensy pin was accidentally set to ground, you would also instantly
fry the Teensy.  Given the very high impedance of both the Teensy ADC and
most oscilloscopes, the impedance of the 200 ohm resistor is negligible in
the low MHz regime.

One interesting thing you'll find in the SPICE model, and I've also
verified in real life, is that as long as you use a transmission line with
a constant impedance (such as the magnet wire twisted pair or CAT5 cable)
then the length of the wire - within reasonable limits - only contributes a
small phase delay rather than decreasing the slew rate.  In hindsight this
made sense, as you are basically sending a high power wave down the wire,
and therefore the slew rate of the wave-front becomes self propagating once
coupled into the wire.  If your wire was REALLY long you definitely would
start running into dispersion and attenuation, but in my experience the
difference between a 10 cm wire and a 3 m wire is practically nonexistent.
The other reason we use wires is that 1) it makes it much easier to
integrate to existing LED setups, and 2) it allows the driver to be farther
away from the microscope, which definitely helps when doing
electrophysiology, where you don't want to touch anything on or near the
microscope (hence one of the motivations for the GUI as well).  That said,
I have fantasized time to time about the speeds I could get with an LED
soldered directly onto the board.  Not practical, but it would be really
cool to see what the upper limit truly is.

In regards to the slow DPAKs, one thing I've found pretty consistent after
reading hundreds of data sheets is that any leads greatly slow down a
device, and the longer the lead - the greater the slow down.  I'd imagine
parasitic induction is the largest culprit, as there is a pretty big
inductive loop under the lead (especially when you also factor in the wire
connected to that lead inside the epoxy package).  The resistance of the
lead will also create an RC filter, especially on something with a fair
amount of capacitance such as a MOSFET.  Along these lines, you will find
that through-hole mosfets are by far the slowest, followed by leaded SMD
packages such as the DPAK.  DFN packages tend to have pretty nice specs
(this is what I used on the original driver) but as stated before, the
custom footprints kind of lock you in to a specific mosfet, and they don't
handle as much current and wattage as a DPAK package.  Then, if you really
want to drool, you should check out the specs on bare die mosfets:
https://www.digikey.com/short/zvqnpz.  Those things are insanely fast with
almost no Rds On and no gate charge, but the footprints are all different,
and I imagine they would pretty hard for an inexperienced person to
solder.  That said, for a more advanced user, they could simply replace the
mosfet footprint in the KiCAD model, and build a driver that could go into
the 10s of MHz if the LED was mounted directly onto the board.

As far as monitoring the optical output waveform, I've used an even more
cobbled together approach by simply putting the LED next to a 2P microscope
and measuring the light going into the PMT.  For example here is the test
of the 20A driver running the 385 nm LED at 18A on our 8 kHz resonant
microscope using a bidirectional scan (note that because it is a resonant
scope there is going to be a bit of a sine distortion at the edges of the
FOV):
Driver sending 18 µs LED pulses slightly out of phase with the microscope:
https://bit.ly/33pTUjU
Here is the same setup but now synced to the microscope so that the the 18
µs pulses are during the flyback: https://bit.ly/3mdEwyJ

By measuring the correlation between the PMT signal and the LED current
signal, I've found that the LED output perfectly matches the LED current
profile, once you account for the LED response curve.  This isn't too
surprising given that LEDs can be driven at well over 1 GHz, so a few MHz
is a walk in the park.  Moral of the story, as long as you keep your LEDs
at a constant temperature, the current can very accurately predict the
output.  Modern LEDs are truly amazing!

Cheers,
   Ben Smith


On Fri, Nov 27, 2020 at 6:18 AM Gordon Scott <[hidden email]> wrote:

> *****
> To join, leave or search the confocal microscopy listserv, go to:
> http://lists.umn.edu/cgi-bin/wa?A0=confocalmicroscopy
> Post images on http://www.imgur.com and include the link in your posting.
> *****
>
> Hi Ben, all
>
> On 26/11/2020 21:41, Benjamin Smith wrote:
> > Another issue with dropping the LED supply voltage is that you take a
> > pretty big speed penalty.  This is because the inductance of the wires
> > going to the LED is the primary limiter to the slew rate at these speeds.
>
>
> I was able to use quite short cables as the LEDs were usually in the
> main unit and the distance to the microscope was covered using light
> guides.  That also has benefits when using some of the microscopy
> techniques involving small electric/magnetic fields.
>
>
> In my setups, the speed was constrained more by the OpAmp's ability to
> drive the MOSFET's gate charge  My speeds were also significantly lower
> at 300kHz maximum.  As you mention, very short pulses are probably best
> done in other ways ... in those cases, often one wants simply to deliver
> a 'package' of light, with only a limited concern of the shape of the
> pulse, provided it's short.
>
>
> You don't say where your waveforms were measured. The scale suggests a
> 55V swing, which I presume is not correct.
>
> At the final output, I generally measured the voltage across the sense
> resistor, rather than elsewhere, as the voltages around the drain and
> LED itself have significantly amplified error components due to the high
> output impedance of the current sink. For an even more 'real' indicative
> view of the light output waveform, I would use a photodiode in a
> horribly hacked-together setup.
>
>
> I fully understand your choice of a DPAK package, though as you allude,
> their performance tends to be a bit 'clunky' in comparison with other
> devices, but there's a huge range to choose from.  I rather suspect the
> physical characteristics of the package itself are a limiting factor.
>
>
> KInd regards,
>
>                            Gordon.
>

--
Benjamin E. Smith, Ph. D.
Imaging Specialist, Vision Science
University of California, Berkeley
195 Life Sciences Addition
Berkeley, CA  94720-3200
Tel  [phone]
Fax [phone]
e-mail: [hidden email]
https://vision.berkeley.edu/faculty/core-grants-nei/core-grant-microscopic-imaging/

[Gordon Scott-3]

*****
To join, leave or search the confocal microscopy listserv, go to:
http://lists.umn.edu/cgi-bin/wa?A0=confocalmicroscopy
Post images on http://www.imgur.com and include the link in your posting.
*****

Hi Ben,

I'm just wondering how useful this is to others on the list. It isn't
hard to delete for those not interested, but I wonder if we should add a
subject tag or if people would prefer us elsewhere.

Perhaps someone with a strong opinion will let us know.  Being here does
make the project visible!

On 27/11/2020 20:17, Benjamin Smith wrote:
>   I've just gotten used to just dividing the values
> by 10 in my head when using a 1x probe.

I guessed, but it's always better to be sure.

> As such, the 1A driver had a 5 Ohm
> current sense resistor, and so a 5V output (50V on the oscilloscope)
> corresponded to a 1A current.

I wonder rather if the amount of swing on the source contributes to the
dynamics issues.  Whilst the situation is different, I used 50mR for the
whole range to 10A, so the voltage signal across the resistor never
exceeds 500mV.  Similarly and trickier in the the OpenSource driver
situation, I kept the anode voltage on the LED about a volt above the
LED's maximum operation voltage, so the swing on the drain of the MOSFET
is also only around 500mV.  I monitored Voltage and temperature with the
uP, in both cases via suitable R/C networks that also gave over-voltage
protection.  With 50mR sense, I was still able to keep the accuracy I
then wanted (~0.1% of FSD, so better than 1% for all real currents).  I
had to do a little fiddling at 0A to avoid any light from LEDs when
they're supposed to be off, whilst also keeping the OPA in a linear
state.  I probably can't say exactly what I did other than, as the
MOSFET must be able to sink a little current in that condition and that
current can't go through the LED, I arranged for it to go elsewhere.

Low voltage swing on the Drain reduces the impact of Qdg as well as the
dissipation of the MOSFET.

> ... if a user accidentally shorts the current sense voltage, then
> the op-amp will fully close the MOSFET which will instantly destroy the
> LED,

For early power tests I used to keep a finger on the tab of the MOSFET
in case the temperature rose too quickly. One day I switched on a
prototype like that and within a second I had switched off again. taken
my finger of of the MOSFET and yelped. Wow that was quick.  Everything
survived. :-)

>   and 2) the Teensy is also connected to the current sense voltage, so
> if the Teensy pin was accidentally set to ground, you would also instantly
> fry the Teensy.

I chose top not connect an ADC there, partly because I trusted the
electronics to do it's job, partly because at that voltage it wouldn't
really tell me that much anyway, partly because I had only so may ADC
inputs to go around.

> Given the very high impedance of both the Teensy ADC and
> most oscilloscopes, the impedance of the 200 ohm resistor is negligible in
> the low MHz regime.

That's between Drain and Teensy, yes?

>
> One interesting thing you'll find in the SPICE model, and I've also
> verified in real life, is that as long as you use a transmission line with
> a constant impedance (such as the magnet wire twisted pair or CAT5 cable)
> then the length of the wire - within reasonable limits - only contributes a
> small phase delay rather than decreasing the slew rate.  In hindsight this
> made sense, as you are basically sending a high power wave down the wire,
> and therefore the slew rate of the wave-front becomes self propagating once
> coupled into the wire.

Indeed ... ideally it should be a properly matched transmission line,
though that's sometimes easier said than achieved. Especially with a
variety of LEDs.

> If your wire was REALLY long you definitely would
> start running into dispersion and attenuation, but in my experience the
> difference between a 10 cm wire and a 3 m wire is practically nonexistent.

Ah, OK.  I'd gained the impression earlier that the lead inductance was
a big issue, but that suggests rather less so.

> The other reason we use wires is that 1) it makes it much easier to
> integrate to existing LED setups, and 2) it allows the driver to be farther
> away from the microscope, which definitely helps when doing
> electrophysiology, where you don't want to touch anything on or near the
> microscope (hence one of the motivations for the GUI as well).

Electrophysiology was the term I couldn't remember.  I'm not a
microscopist and not familiar with the constraints. It's interesting to
me that twisted pair is suitable. Presumably Cat5/Cat6  STP would be
quite good then.  I never heard of any complaints about the only
long-leaded product I did, but the cable was shielded and we used
twisted pairs within it.

> That said,
> I have fantasized time to time about the speeds I could get with an LED
> soldered directly onto the board.  Not practical, but it would be really
> cool to see what the upper limit truly is.

Well, it needs only the OpAmp/Sink circuit and sufficient(!) local
decoupling at the LED. Getting control signals down a transmission line
would be easier and more predictable.  Perhaps now for another day, though.

>
> In regards to the slow DPAKs, one thing I've found pretty consistent after
> reading hundreds of data sheets is that any leads greatly slow down a
> device, and the longer the lead - the greater the slow down.  I'd imagine
> parasitic induction is the largest culprit, as there is a pretty big
> inductive loop under the lead (especially when you also factor in the wire
> connected to that lead inside the epoxy package).  The resistance of the
> lead will also create an RC filter, especially on something with a fair
> amount of capacitance such as a MOSFET.  Along these lines, you will find
> that through-hole mosfets are by far the slowest, followed by leaded SMD
> packages such as the DPAK.  DFN packages tend to have pretty nice specs
> (this is what I used on the original driver) but as stated before, the
> custom footprints kind of lock you in to a specific mosfet, and they don't
> handle as much current and wattage as a DPAK package.  Then, if you really
> want to drool, you should check out the specs on bare die mosfets:
> https://www.digikey.com/short/zvqnpz.  Those things are insanely fast with
> almost no Rds On and no gate charge, but the footprints are all different,
> and I imagine they would pretty hard for an inexperienced person to
> solder.

Bare die are not for DIY. Getting the die down onto a substrate isn't so
difficult, but wire-bonding is not a DIY task.  That said, with a
suitable machine it isn't hard, either.  It was how that ex-employer was
able to produce LEDs that we could run at, for the time, silly
currents.  Bare die, straight onto substantial copper slugs and then
onto more conventional heatsinks.  My guess is they now mostly(?) use
pre-packaged LEDs. Today one can almost buy high-powered, wavelength
specified, LEDs at the local store.

There are lots of MOSFETs on a pretty standard SO-8-like thermal package
and they seem to be consistently faster and have a lower Rdson that
DPAKs.  They may well be 'twitchy'; I believe most are aimed primarily
at SMPSUs.  I can't offhand remember if I ever used them for the sink
MOSFET.  I think I may have used them only in SMPSUs.  Most of the 8-pin
SO-8-like DFN packs seem to be pretty compatible.  Often  around 1mR
Rdson, Vgs 2.5V logic-driveable. Ultra-low Rdson is only really
significant for switching, so long as it's low enough to allow the
device to stay linear with a low voltage across it.

> That said, for a more advanced user, they could simply replace the
> mosfet footprint in the KiCAD model, and build a driver that could go into
> the 10s of MHz if the LED was mounted directly onto the board.

I would think so.  Precision was fall, but my guess is that, provided it
was clean and repeatable, precision would be a minor issue.


> As far as monitoring the optical output waveform, I've used an even more
> cobbled together

:-) .. Oh I doubt it ... mine was simply a photodiode and resistor
straight onto the scope probe.  I'd trust the general impression, but
nothing more.  On a plus side, it should have been as fast as my scope
can do, which is 70MHz.  With the kind of light-levels I had, there was
no problem needing amplification.  I simply declined to believe
linearity.  All I was looking for, really, was propagation delay. 
Someone else checked the linearity of the light output and, where
feasible, I applied a quadratic to correct the curve.  Most of my
photosensor experience is at the low light end of the scale and with
pretty slow signals.

> Moral of the story, as long as you keep your LEDs
> at a constant temperature, the current can very accurately predict the
> output.  Modern LEDs are truly amazing!

In an early model we used a Peltier to keep the temperature very
stable.  Back then, I'm not sure how aware people were of some of the
temperature and current.  We certainly had only the knowledge and our
own experiments for the LEDs we were using. I don't recall the figures
being published anywhere, though they may have been.  In truth I think
temperature doesn't normally need to be all _that_ stable, provided it's
kept inside a moderate range. Your massive heat-pipe cooler should do
that well.

Yes, modern LEDs _are_ amazing.  That's probably packaging and
understanding more than anything, though there have certainly been some
interesting breakthroughs at the die level and I presume at the
chemistry level.  It's one of the reasons I've loved electronics all
through my career.  It's a bit like climbing and false summits, except
that each new 'summit' summit is normally "Wow!  will you look at
that!", let's go there!  Frustratingly, there appear too many such
summits for just one life.

BTW, I'm not suggesting in any way that we "throw everything up in the
air and start over".  Maybe some tweaks, maybe not. We learn and we can
put different things into future incarnations.

Kind regards,
                      Gordon.

[Mike Nelson]

*****
To join, leave or search the confocal microscopy listserv, go to:
http://lists.umn.edu/cgi-bin/wa?A0=confocalmicroscopy
Post images on http://www.imgur.com and include the link in your posting.
*****

"I'm just wondering how useful this is to others on the list. It isn't
hard to delete for those not interested, but I wonder if we should add a
subject tag or if people would prefer us elsewhere. "
Hi Gordon,
  I, for one, have no *immediate *use for this information, but I think it
will be an *amazing* resource in the near future when I start getting my
hands dirty with microscope design. Having a record of all of this is
fantastic, though if you really wanted to take it to the microscopy forum,
that might also be another option where those interested might find it in
the future (or present).
https://forum.microlist.org/

Cheers,
Mike

On Sun, Nov 29, 2020 at 10:23 AM Gordon Scott <[hidden email]> wrote:

> *****
> To join, leave or search the confocal microscopy listserv, go to:
> http://lists.umn.edu/cgi-bin/wa?A0=confocalmicroscopy
> Post images on http://www.imgur.com and include the link in your posting.
> *****
>
> Hi Ben,
>
> I'm just wondering how useful this is to others on the list. It isn't
> hard to delete for those not interested, but I wonder if we should add a
> subject tag or if people would prefer us elsewhere.
>
> Perhaps someone with a strong opinion will let us know.  Being here does
> make the project visible!
>
> On 27/11/2020 20:17, Benjamin Smith wrote:
> >   I've just gotten used to just dividing the values
> > by 10 in my head when using a 1x probe.
>
> I guessed, but it's always better to be sure.
>
> > As such, the 1A driver had a 5 Ohm
> > current sense resistor, and so a 5V output (50V on the oscilloscope)
> > corresponded to a 1A current.
>
> I wonder rather if the amount of swing on the source contributes to the
> dynamics issues.  Whilst the situation is different, I used 50mR for the
> whole range to 10A, so the voltage signal across the resistor never
> exceeds 500mV.  Similarly and trickier in the the OpenSource driver
> situation, I kept the anode voltage on the LED about a volt above the
> LED's maximum operation voltage, so the swing on the drain of the MOSFET
> is also only around 500mV.  I monitored Voltage and temperature with the
> uP, in both cases via suitable R/C networks that also gave over-voltage
> protection.  With 50mR sense, I was still able to keep the accuracy I
> then wanted (~0.1% of FSD, so better than 1% for all real currents).  I
> had to do a little fiddling at 0A to avoid any light from LEDs when
> they're supposed to be off, whilst also keeping the OPA in a linear
> state.  I probably can't say exactly what I did other than, as the
> MOSFET must be able to sink a little current in that condition and that
> current can't go through the LED, I arranged for it to go elsewhere.
>
> Low voltage swing on the Drain reduces the impact of Qdg as well as the
> dissipation of the MOSFET.
>
> > ... if a user accidentally shorts the current sense voltage, then
> > the op-amp will fully close the MOSFET which will instantly destroy the
> > LED,
>
> For early power tests I used to keep a finger on the tab of the MOSFET
> in case the temperature rose too quickly. One day I switched on a
> prototype like that and within a second I had switched off again. taken
> my finger of of the MOSFET and yelped. Wow that was quick.  Everything
> survived. :-)
>
> >   and 2) the Teensy is also connected to the current sense voltage, so
> > if the Teensy pin was accidentally set to ground, you would also
> instantly
> > fry the Teensy.
>
> I chose top not connect an ADC there, partly because I trusted the
> electronics to do it's job, partly because at that voltage it wouldn't
> really tell me that much anyway, partly because I had only so may ADC
> inputs to go around.
>
> > Given the very high impedance of both the Teensy ADC and
> > most oscilloscopes, the impedance of the 200 ohm resistor is negligible
> in
> > the low MHz regime.
>
> That's between Drain and Teensy, yes?
>
> >
> > One interesting thing you'll find in the SPICE model, and I've also
> > verified in real life, is that as long as you use a transmission line
> with
> > a constant impedance (such as the magnet wire twisted pair or CAT5 cable)
> > then the length of the wire - within reasonable limits - only
> contributes a
> > small phase delay rather than decreasing the slew rate.  In hindsight
> this
> > made sense, as you are basically sending a high power wave down the wire,
> > and therefore the slew rate of the wave-front becomes self propagating
> once
> > coupled into the wire.
>
> Indeed ... ideally it should be a properly matched transmission line,
> though that's sometimes easier said than achieved. Especially with a
> variety of LEDs.
>
> > If your wire was REALLY long you definitely would
> > start running into dispersion and attenuation, but in my experience the
> > difference between a 10 cm wire and a 3 m wire is practically
> nonexistent.
>
> Ah, OK.  I'd gained the impression earlier that the lead inductance was
> a big issue, but that suggests rather less so.
>
> > The other reason we use wires is that 1) it makes it much easier to
> > integrate to existing LED setups, and 2) it allows the driver to be
> farther
> > away from the microscope, which definitely helps when doing
> > electrophysiology, where you don't want to touch anything on or near the
> > microscope (hence one of the motivations for the GUI as well).
>
> Electrophysiology was the term I couldn't remember.  I'm not a
> microscopist and not familiar with the constraints. It's interesting to
> me that twisted pair is suitable. Presumably Cat5/Cat6  STP would be
> quite good then.  I never heard of any complaints about the only
> long-leaded product I did, but the cable was shielded and we used
> twisted pairs within it.
>
> > That said,
> > I have fantasized time to time about the speeds I could get with an LED
> > soldered directly onto the board.  Not practical, but it would be really
> > cool to see what the upper limit truly is.
>
> Well, it needs only the OpAmp/Sink circuit and sufficient(!) local
> decoupling at the LED. Getting control signals down a transmission line
> would be easier and more predictable.  Perhaps now for another day, though.
>
> >
> > In regards to the slow DPAKs, one thing I've found pretty consistent
> after
> > reading hundreds of data sheets is that any leads greatly slow down a
> > device, and the longer the lead - the greater the slow down.  I'd imagine
> > parasitic induction is the largest culprit, as there is a pretty big
> > inductive loop under the lead (especially when you also factor in the
> wire
> > connected to that lead inside the epoxy package).  The resistance of the
> > lead will also create an RC filter, especially on something with a fair
> > amount of capacitance such as a MOSFET.  Along these lines, you will find
> > that through-hole mosfets are by far the slowest, followed by leaded SMD
> > packages such as the DPAK.  DFN packages tend to have pretty nice specs
> > (this is what I used on the original driver) but as stated before, the
> > custom footprints kind of lock you in to a specific mosfet, and they
> don't
> > handle as much current and wattage as a DPAK package.  Then, if you
> really
> > want to drool, you should check out the specs on bare die mosfets:
> > https://www.digikey.com/short/zvqnpz.  Those things are insanely fast
> with
> > almost no Rds On and no gate charge, but the footprints are all
> different,
> > and I imagine they would pretty hard for an inexperienced person to
> > solder.
>
> Bare die are not for DIY. Getting the die down onto a substrate isn't so
> difficult, but wire-bonding is not a DIY task.  That said, with a
> suitable machine it isn't hard, either.  It was how that ex-employer was
> able to produce LEDs that we could run at, for the time, silly
> currents.  Bare die, straight onto substantial copper slugs and then
> onto more conventional heatsinks.  My guess is they now mostly(?) use
> pre-packaged LEDs. Today one can almost buy high-powered, wavelength
> specified, LEDs at the local store.
>
> There are lots of MOSFETs on a pretty standard SO-8-like thermal package
> and they seem to be consistently faster and have a lower Rdson that
> DPAKs.  They may well be 'twitchy'; I believe most are aimed primarily
> at SMPSUs.  I can't offhand remember if I ever used them for the sink
> MOSFET.  I think I may have used them only in SMPSUs.  Most of the 8-pin
> SO-8-like DFN packs seem to be pretty compatible.  Often  around 1mR
> Rdson, Vgs 2.5V logic-driveable. Ultra-low Rdson is only really
> significant for switching, so long as it's low enough to allow the
> device to stay linear with a low voltage across it.
>
> > That said, for a more advanced user, they could simply replace the
> > mosfet footprint in the KiCAD model, and build a driver that could go
> into
> > the 10s of MHz if the LED was mounted directly onto the board.
>
> I would think so.  Precision was fall, but my guess is that, provided it
> was clean and repeatable, precision would be a minor issue.
>
>
> > As far as monitoring the optical output waveform, I've used an even more
> > cobbled together
>
> :-) .. Oh I doubt it ... mine was simply a photodiode and resistor
> straight onto the scope probe.  I'd trust the general impression, but
> nothing more.  On a plus side, it should have been as fast as my scope
> can do, which is 70MHz.  With the kind of light-levels I had, there was
> no problem needing amplification.  I simply declined to believe
> linearity.  All I was looking for, really, was propagation delay.
> Someone else checked the linearity of the light output and, where
> feasible, I applied a quadratic to correct the curve.  Most of my
> photosensor experience is at the low light end of the scale and with
> pretty slow signals.
>
> > Moral of the story, as long as you keep your LEDs
> > at a constant temperature, the current can very accurately predict the
> > output.  Modern LEDs are truly amazing!
>
> In an early model we used a Peltier to keep the temperature very
> stable.  Back then, I'm not sure how aware people were of some of the
> temperature and current.  We certainly had only the knowledge and our
> own experiments for the LEDs we were using. I don't recall the figures
> being published anywhere, though they may have been.  In truth I think
> temperature doesn't normally need to be all _that_ stable, provided it's
> kept inside a moderate range. Your massive heat-pipe cooler should do
> that well.
>
> Yes, modern LEDs _are_ amazing.  That's probably packaging and
> understanding more than anything, though there have certainly been some
> interesting breakthroughs at the die level and I presume at the
> chemistry level.  It's one of the reasons I've loved electronics all
> through my career.  It's a bit like climbing and false summits, except
> that each new 'summit' summit is normally "Wow!  will you look at
> that!", let's go there!  Frustratingly, there appear too many such
> summits for just one life.
>
> BTW, I'm not suggesting in any way that we "throw everything up in the
> air and start over".  Maybe some tweaks, maybe not. We learn and we can
> put different things into future incarnations.
>
> Kind regards,
>                       Gordon.
>

[Benjamin Smith]

*****
To join, leave or search the confocal microscopy listserv, go to:
http://lists.umn.edu/cgi-bin/wa?A0=confocalmicroscopy
Post images on http://www.imgur.com and include the link in your posting.
*****

Sure.  Here is what was written on my side off-list that may be helpful:

*Current sense voltage choice:*


In regards to using 5V driving voltage on the original driver, and a 3.3V
driving voltage on the current driver, is for three reasons: 1) I've found
I can get faster slew rates the larger the voltage step, 2) small voltage
steps tended to also have a long phase delay with mV steps taking almost
100 µs, and 3) it gave us wider dynamic range since there is a limit to the
noise floor on an op-amp, and therefore the only way to really increase the
analog dynamic range is by increasing the maximum voltage.

One thing that could possibly fix this issue would be to have a tunable
negative input voltage and tunable negative op-amp rail for turning the LED
off.  As it sounds like you also found, due to the input offset voltage,
sending 0V to the op-amp actually leaves the LED dimly on, therefore you
need a slight negative voltage to turn the LED off.   The catch is that
this means I need to both send a small negative voltage to the
non-inverting input on the op-amp, as well as have the negative side of the
op-amp on a negative voltage so that it can safely handle the negative
voltage input.



That said, I think I just had a duh moment, the op-amp can handle up to a
0.7V differential on the inputs.  Therefore, the op-amp could very likely
be powered with a 0-12V supply with a small negative input voltage (the
current negative input is -0.25V).  This would help resolve a slight phase
delay the driver currently has, where it has to swing the gate all the way
from -1.8V to around 3-4V before the LED even begins to turn on.
Therefore, reducing that swing to 0-4V would speed things up.

With that in mind - if you could find a compatible 5V mosfet with a
sufficiently low gate charge and a low resistance current sense resistor,
you should be able to get up to  almost 10 MHz with this op-amp:
https://www.digikey.com/en/products/detail/analog-devices-inc/LTC6268IS6-10-TRMPBF/5253537

The op-amp still has the same output current, so the speed up would likely
need to be paired with a DFN mosfet to get the gate charge low enough.  I
used this op-amp in the very, very first draft (before I knew much about
anything circuit design) and it was very fast, but it can be hard to find a
good mosfet to pair it with.  Along those lines the LT6200-10's 12V range
opens up a much wider range of available mosfets (as most of the good ones
are fully open at 10V), so maybe the speed penalty is worth the versatility?



*Unplanned destructive testing of mosfets:*



"For early power tests I used to keep a finger on the tab of the MOSFET
in case the temperature rose too quickly. "


I wish I had this foresight in the previous design.  In that design the
mosfet was buried between a header and the heatsink, and so was
unreachable.  I originally tested the 1A version using a shorted output to
prevent accidentally blowing out an LED if I did something stupid (it's
also nice to not have a 1A LED shining at you while troubleshooting).  I
then had a total brain-fart, and tested the 20A version also with a short.
The end result being that my poor DFN mosfet got hit with 80W with only a
1oz/ft copper pad to a 40x40mm heatsink to cool it.  The fact it survived
as long as it did (about 20 seconds) before it finally gave up the magic
smoke is a testament to just how good that chip really was.  That said,
with the current driver design the mosfet temperature rose only 10°C under
12W of heating, so it definitely looks like the goal of making a more
thermally resilient driver for high current applications has definitely
been achieved!



And thanks for the insight on the die mosfets.  I couldn't find any good
whitepapers on how to use them, which it sounds like I correctly took as
them not being beginner friendly.


*Wire inductance:*



With the 20A driver, I used the classic wire loop connected to an
oscilloscope to sniff out any EMI from the driver.  The driver itself was
enclosed in an aluminum box with Faraday fan guards, so nothing was leaking
out of that, however even outside the box the biggest source of EMI was
still the SEPIC converters despite liberal use of grounded guard traces,
ferrite beads, and shielded inductors.  The driver circuit itself had a
little bit of EMI, but I guess thanks to careful grounding to minimize
inductance, it was pretty negligible (that and the bandwidth of the LED is
MUCH lower than the bandwidth of a SEPIC converter).  The other major
source was the LED.  This makes sense as there is an appreciable gap
between leads on a COB LED (relative to twisted enamel wire at least), so
the LED itself had by far the strongest EMI emission.  It was also a pretty
cool confirmation of just how low the inductance is in an enamel wire
twisted pair that even with a 20A 1 MHz wave being transmitted through
them, there was virtually no EMI being radiated (and the little bit that
was radiated is far more likely from the resistance of the 12 AWG wire than
the inductance).



*Impedance matching:*



Your insights on this match my own.  I played around with impedance
matching in the SPICE simulation, but it was very specific to the wire
used, and so people would need a different impedance setups for each wire
choice (such as twisted pair, enamel twisted pair, CAT5, BNC, straight pair
such as on the Thorlabs LEDs).  On top of that, the impedance of the COB
LED is much higher than the wire, so you would also need an impedance match
on the LED end of the wire as well.  By that point even I would never want
to put such as setup together, let alone design one.  The impedance was
also affected by bandwidth making the issue even more complicated.  Thus,
adjusting the op-amp compensation instead proved to be a MUCH simpler
one-size-fits-all solution with pretty much the same performance as
impedance matching.





*That's between Drain and Teensy, yes?*



Yep.  The drain has four connections total.  One connection is to the 200
Ohm resistor, with the Teensy ADC and the RJ45 connection on the other side
of the resistor.  Another connection, of course, is the current sense
resistors.  The third connection is a trimpot that connects back to the
inverting input on the op-amp for adjustable compensation.  The fourth
connection is a TVS diode that bridges the source and drain of the mosfet.
The mosfet can handle up to 100V, so the TVS diode fully conducts at 97V.
This is really only needed for rare edge case of high current and high
voltage applications with long wires, but it also just makes me feel better
knowing it is there.

In regards to the series resistor, people have found that they did not see
any attenuation on the bandwidth of the ADC with a 10k series resistor.
The reason for choosing 200 ohms is simply because I already need two 200
ohm resistors for the voltage divider to make the -0.25V input for the
opamp, and so I already had two spare 200 ohm resistors on the 4x 200 ohm
resistor array.  As 200 ohms was already more than enough for what I
needed, I used that.  The fourth 200 ohm resistor was used as series
resistor for a 0-3.3V clamp on the direct RJ45 to op-amp connection to at
least try to protect the Teensy and driver from being over-driven (it
protects only at +6V to -3V, so not much protection but at least will save
the driver if connected to a 5V TTL signal).

"I chose top not connect an ADC there, partly because I trusted the
electronics to do it's job, partly because at that voltage it wouldn't
really tell me that much anyway, partly because I had only so may ADC
inputs to go around. "



The original driver didn't have this connection for the same reasons (the
Arduino only has 6 analog pins at 250 kHz), and instead only had a header
connection for externally monitoring what the LED was doing with an
oscilloscope.  The main motivation for the connection in this driver is
since it requires  seeing the LED waveform to adjust the compensation, I
wanted a way for people to use the driver even if they didn't have an
oscilloscope.  On top of this, the Teensy has two internal ADCs multiplexed
to 20 pins, so there is a plethora to choose from.  And on top of that
since the ADCs support DMA, they can run at 1.1 MS/s, which is good enough
for tuning the driver.

As an added bonus, this same "calibration" window in the GUI allows the
user to quickly confirm that the LED and driver are working correctly at
the start of an experiment, which is especially helpful for fully enclosed
LED setups.

"Presumably Cat5/Cat6  STP would be quite good then."



In one of my setups I used CAT5 instead of the twisted enamel wire out of
convenience, and it proved to be as fast if not just a hair faster than
enamel wire.  That said, it was also used to drive a diode laser, so that
may also have been part of it.  Either way, that, and the discovery that
thanks to security cameras you can buy CAT5 to BNC baluns for super cheap),
was the motivation to switch the design fully over to CAT5 both for the
LEDs and I/O connections.  The 4x RJ45 connecter also has a WAY smaller
footprint and far lower cost than the equivalent 16 coaxial connections.


*Summary:*



I can say, for my side of things, I am hoping to have a driver design that
is sufficiently easy to assemble and use, that there would be a low barrier
to people building their own drivers for their research.  For example, in
the assembly guide I am going to write (similar to this one:
https://github.com/Llamero/Light_Color_and_Intensity_Datalogger/blob/master/Data%20logger%20assembly%20manual.pdf).
One of the biggest hurdles I think will be to convince people how
ridiculously easy reflow soldering is.  Before this project I had only hand
soldered, and had this mindset that reflow soldering was super complicated
elite level stuff.  I watched many videos and still was nervous.  Then,
when I built my first driver, I realized that reflow soldering is insanely
easy and takes absolutely no skill compared to hand-soldering.  If you can
spackle a hole in a wall, you can reflow solder.  All the design work is
already done (especially getting a circuit of this complexity routed onto a
1-layer PCB), so all a user needs to do is stencil on some paste, place the
parts, toss it on a hot plate, upload the code, and voila you have a fancy
new driver!


Ease of assembly is also why there are no through-hole components, or parts
that need to be hand soldered on.  The driver board is also 100 mm x 100
mm, which allows it to fit perfectly inside a standard project box without
needing to wire connections.  Therefore, you only need to drill out holes
for the pushbuttons, pot, switch, and back connections and you have an
enclosed driver - no wiring needed whatsoever!  That and PCBWay prices
metal core PCBs in a stepwise manner, so boards below 100 mm x 100 mm are
all priced the same, so that became a fixed working constraint (hence why
space is used fairly efficiently).

Other than the lack of any hand soldering or wiring for the driver, and the
use of the Teensy which is easily programmable, the other thing I really
like about the current driver is that it is on a metal core PCB.  This not
only allows thermal management to be done in the 3D dimension, but also
makes for a spectacular ground plane (especially in high current
applications).  I did a lot of research on galvanic corrosion to make sure
using the aluminum itself as a grounding plane would be safe, and from what
I read it will be perfectly fine in a laboratory setting, and outside of
that, there is a coating you can buy at the hardware store for $6 if you
are going to use the LED driver outdoors for some reason.  That said, using
the aluminum as a ground plane is not essential (the top layer has a
low-inductance continuous ground plan on its own), so in cases where
grounding to the aluminum may prove problematic, you can just use nylon
standoffs).

On Wed, Dec 2, 2020 at 8:17 PM Michael S. Nelson <[hidden email]> wrote:

> *****
> To join, leave or search the confocal microscopy listserv, go to:
> http://lists.umn.edu/cgi-bin/wa?A0=confocalmicroscopy
> Post images on http://www.imgur.com and include the link in your posting.
> *****
>
> "I'm just wondering how useful this is to others on the list. It isn't
> hard to delete for those not interested, but I wonder if we should add a
> subject tag or if people would prefer us elsewhere. "
> Hi Gordon,
>   I, for one, have no *immediate *use for this information, but I think it
> will be an *amazing* resource in the near future when I start getting my
> hands dirty with microscope design. Having a record of all of this is
> fantastic, though if you really wanted to take it to the microscopy forum,
> that might also be another option where those interested might find it in
> the future (or present).
> https://forum.microlist.org/
>
> Cheers,
> Mike
>
> On Sun, Nov 29, 2020 at 10:23 AM Gordon Scott <[hidden email]> wrote:
>
> > *****
> > To join, leave or search the confocal microscopy listserv, go to:
> > http://lists.umn.edu/cgi-bin/wa?A0=confocalmicroscopy
> > Post images on http://www.imgur.com and include the link in your
> posting.
> > *****
> >
> > Hi Ben,
> >
> > I'm just wondering how useful this is to others on the list. It isn't
> > hard to delete for those not interested, but I wonder if we should add a
> > subject tag or if people would prefer us elsewhere.
> >
> > Perhaps someone with a strong opinion will let us know.  Being here does
> > make the project visible!
> >
> > On 27/11/2020 20:17, Benjamin Smith wrote:
> > >   I've just gotten used to just dividing the values
> > > by 10 in my head when using a 1x probe.
> >
> > I guessed, but it's always better to be sure.
> >
> > > As such, the 1A driver had a 5 Ohm
> > > current sense resistor, and so a 5V output (50V on the oscilloscope)
> > > corresponded to a 1A current.
> >
> > I wonder rather if the amount of swing on the source contributes to the
> > dynamics issues.  Whilst the situation is different, I used 50mR for the
> > whole range to 10A, so the voltage signal across the resistor never
> > exceeds 500mV.  Similarly and trickier in the the OpenSource driver
> > situation, I kept the anode voltage on the LED about a volt above the
> > LED's maximum operation voltage, so the swing on the drain of the MOSFET
> > is also only around 500mV.  I monitored Voltage and temperature with the
> > uP, in both cases via suitable R/C networks that also gave over-voltage
> > protection.  With 50mR sense, I was still able to keep the accuracy I
> > then wanted (~0.1% of FSD, so better than 1% for all real currents).  I
> > had to do a little fiddling at 0A to avoid any light from LEDs when
> > they're supposed to be off, whilst also keeping the OPA in a linear
> > state.  I probably can't say exactly what I did other than, as the
> > MOSFET must be able to sink a little current in that condition and that
> > current can't go through the LED, I arranged for it to go elsewhere.
> >
> > Low voltage swing on the Drain reduces the impact of Qdg as well as the
> > dissipation of the MOSFET.
> >
> > > ... if a user accidentally shorts the current sense voltage, then
> > > the op-amp will fully close the MOSFET which will instantly destroy the
> > > LED,
> >
> > For early power tests I used to keep a finger on the tab of the MOSFET
> > in case the temperature rose too quickly. One day I switched on a
> > prototype like that and within a second I had switched off again. taken
> > my finger of of the MOSFET and yelped. Wow that was quick.  Everything
> > survived. :-)
> >
> > >   and 2) the Teensy is also connected to the current sense voltage, so
> > > if the Teensy pin was accidentally set to ground, you would also
> > instantly
> > > fry the Teensy.
> >
> > I chose top not connect an ADC there, partly because I trusted the
> > electronics to do it's job, partly because at that voltage it wouldn't
> > really tell me that much anyway, partly because I had only so may ADC
> > inputs to go around.
> >
> > > Given the very high impedance of both the Teensy ADC and
> > > most oscilloscopes, the impedance of the 200 ohm resistor is negligible
> > in
> > > the low MHz regime.
> >
> > That's between Drain and Teensy, yes?
> >
> > >
> > > One interesting thing you'll find in the SPICE model, and I've also
> > > verified in real life, is that as long as you use a transmission line
> > with
> > > a constant impedance (such as the magnet wire twisted pair or CAT5
> cable)
> > > then the length of the wire - within reasonable limits - only
> > contributes a
> > > small phase delay rather than decreasing the slew rate.  In hindsight
> > this
> > > made sense, as you are basically sending a high power wave down the
> wire,
> > > and therefore the slew rate of the wave-front becomes self propagating
> > once
> > > coupled into the wire.
> >
> > Indeed ... ideally it should be a properly matched transmission line,
> > though that's sometimes easier said than achieved. Especially with a
> > variety of LEDs.
> >
> > > If your wire was REALLY long you definitely would
> > > start running into dispersion and attenuation, but in my experience the
> > > difference between a 10 cm wire and a 3 m wire is practically
> > nonexistent.
> >
> > Ah, OK.  I'd gained the impression earlier that the lead inductance was
> > a big issue, but that suggests rather less so.
> >
> > > The other reason we use wires is that 1) it makes it much easier to
> > > integrate to existing LED setups, and 2) it allows the driver to be
> > farther
> > > away from the microscope, which definitely helps when doing
> > > electrophysiology, where you don't want to touch anything on or near
> the
> > > microscope (hence one of the motivations for the GUI as well).
> >
> > Electrophysiology was the term I couldn't remember.  I'm not a
> > microscopist and not familiar with the constraints. It's interesting to
> > me that twisted pair is suitable. Presumably Cat5/Cat6  STP would be
> > quite good then.  I never heard of any complaints about the only
> > long-leaded product I did, but the cable was shielded and we used
> > twisted pairs within it.
> >
> > > That said,
> > > I have fantasized time to time about the speeds I could get with an LED
> > > soldered directly onto the board.  Not practical, but it would be
> really
> > > cool to see what the upper limit truly is.
> >
> > Well, it needs only the OpAmp/Sink circuit and sufficient(!) local
> > decoupling at the LED. Getting control signals down a transmission line
> > would be easier and more predictable.  Perhaps now for another day,
> though.
> >
> > >
> > > In regards to the slow DPAKs, one thing I've found pretty consistent
> > after
> > > reading hundreds of data sheets is that any leads greatly slow down a
> > > device, and the longer the lead - the greater the slow down.  I'd
> imagine
> > > parasitic induction is the largest culprit, as there is a pretty big
> > > inductive loop under the lead (especially when you also factor in the
> > wire
> > > connected to that lead inside the epoxy package).  The resistance of
> the
> > > lead will also create an RC filter, especially on something with a fair
> > > amount of capacitance such as a MOSFET.  Along these lines, you will
> find
> > > that through-hole mosfets are by far the slowest, followed by leaded
> SMD
> > > packages such as the DPAK.  DFN packages tend to have pretty nice specs
> > > (this is what I used on the original driver) but as stated before, the
> > > custom footprints kind of lock you in to a specific mosfet, and they
> > don't
> > > handle as much current and wattage as a DPAK package.  Then, if you
> > really
> > > want to drool, you should check out the specs on bare die mosfets:
> > > https://www.digikey.com/short/zvqnpz.  Those things are insanely fast
> > with
> > > almost no Rds On and no gate charge, but the footprints are all
> > different,
> > > and I imagine they would pretty hard for an inexperienced person to
> > > solder.
> >
> > Bare die are not for DIY. Getting the die down onto a substrate isn't so
> > difficult, but wire-bonding is not a DIY task.  That said, with a
> > suitable machine it isn't hard, either.  It was how that ex-employer was
> > able to produce LEDs that we could run at, for the time, silly
> > currents.  Bare die, straight onto substantial copper slugs and then
> > onto more conventional heatsinks.  My guess is they now mostly(?) use
> > pre-packaged LEDs. Today one can almost buy high-powered, wavelength
> > specified, LEDs at the local store.
> >
> > There are lots of MOSFETs on a pretty standard SO-8-like thermal package
> > and they seem to be consistently faster and have a lower Rdson that
> > DPAKs.  They may well be 'twitchy'; I believe most are aimed primarily
> > at SMPSUs.  I can't offhand remember if I ever used them for the sink
> > MOSFET.  I think I may have used them only in SMPSUs.  Most of the 8-pin
> > SO-8-like DFN packs seem to be pretty compatible.  Often  around 1mR
> > Rdson, Vgs 2.5V logic-driveable. Ultra-low Rdson is only really
> > significant for switching, so long as it's low enough to allow the
> > device to stay linear with a low voltage across it.
> >
> > > That said, for a more advanced user, they could simply replace the
> > > mosfet footprint in the KiCAD model, and build a driver that could go
> > into
> > > the 10s of MHz if the LED was mounted directly onto the board.
> >
> > I would think so.  Precision was fall, but my guess is that, provided it
> > was clean and repeatable, precision would be a minor issue.
> >
> >
> > > As far as monitoring the optical output waveform, I've used an even
> more
> > > cobbled together
> >
> > :-) .. Oh I doubt it ... mine was simply a photodiode and resistor
> > straight onto the scope probe.  I'd trust the general impression, but
> > nothing more.  On a plus side, it should have been as fast as my scope
> > can do, which is 70MHz.  With the kind of light-levels I had, there was
> > no problem needing amplification.  I simply declined to believe
> > linearity.  All I was looking for, really, was propagation delay.
> > Someone else checked the linearity of the light output and, where
> > feasible, I applied a quadratic to correct the curve.  Most of my
> > photosensor experience is at the low light end of the scale and with
> > pretty slow signals.
> >
> > > Moral of the story, as long as you keep your LEDs
> > > at a constant temperature, the current can very accurately predict the
> > > output.  Modern LEDs are truly amazing!
> >
> > In an early model we used a Peltier to keep the temperature very
> > stable.  Back then, I'm not sure how aware people were of some of the
> > temperature and current.  We certainly had only the knowledge and our
> > own experiments for the LEDs we were using. I don't recall the figures
> > being published anywhere, though they may have been.  In truth I think
> > temperature doesn't normally need to be all _that_ stable, provided it's
> > kept inside a moderate range. Your massive heat-pipe cooler should do
> > that well.
> >
> > Yes, modern LEDs _are_ amazing.  That's probably packaging and
> > understanding more than anything, though there have certainly been some
> > interesting breakthroughs at the die level and I presume at the
> > chemistry level.  It's one of the reasons I've loved electronics all
> > through my career.  It's a bit like climbing and false summits, except
> > that each new 'summit' summit is normally "Wow!  will you look at
> > that!", let's go there!  Frustratingly, there appear too many such
> > summits for just one life.
> >
> > BTW, I'm not suggesting in any way that we "throw everything up in the
> > air and start over".  Maybe some tweaks, maybe not. We learn and we can
> > put different things into future incarnations.
> >
> > Kind regards,
> >                       Gordon.
> >
>

--
Benjamin E. Smith, Ph. D.
Imaging Specialist, Vision Science
University of California, Berkeley
195 Life Sciences Addition
Berkeley, CA  94720-3200
Tel  [phone]
Fax [phone]
e-mail: [hidden email]
https://vision.berkeley.edu/faculty/core-grants-nei/core-grant-microscopic-imaging/

[Benjamin Smith]

*****
To join, leave or search the confocal microscopy listserv, go to:
http://lists.umn.edu/cgi-bin/wa?A0=confocalmicroscopy
Post images on http://www.imgur.com and include the link in your posting.
*****

For the really esoteric, here is today's part 2 of my side of the off-list
conversation:

*Spice model insights and real-world comparison:*



Below are a bunch of plots from the SPICE model.  I also shortened the PWM
to better match that used on the oscilloscope trace.  It is really striking
just how accurate the SPICE model is compared to the real-world output!
One fun thing I looked into, which I never before bothered to confirm as it
didn't impact the driver performance, is where that initial step up on the
Isense voltage came from if it wasn't LED current.  Turns out it was
obvious once looking over the circuit, it is the coupling of the
compensation capacitor to the Isense voltage (see trace below) .  Hindsight
is 20/20 I guess.

The plots also clearly show that if the gate voltage could be held closer
to the Vgs on of the mosfet then you would get a much shorter phase delay.
This could be accomplished with a voltage clamp, but I'm really not sure
the added complexity is worth fixing something that can also be fixed in
software (via trigger delays), especially considering that the optimal
clamp voltage would have to be tuned for different mosfets used.

Spice model of current sense voltage (1A to LED): https://bit.ly/33ClTgx

Real word oscilloscope trace of current sense voltage (1A shorted):
https://bit.ly/33DGWiE

Spice model of LED current – shows that initial voltage step is not due to
LED current: https://bit.ly/36yYmiA

Spice model of compensation cap voltage and current sense voltage, showing
that the initial voltage step is due to coupling of the cap with the
current sense voltage: https://bit.ly/36yyx27

Spice model of mosfet gate voltage confirming that having to clear out the
negative voltage on the gate causes the observed phase delay:
https://bit.ly/3lykRs5




*LED Driver bandwidth is directly proportional to op-amp GBW:*



Also, in regard to op-amp speed and driver performance, I've found there to
be a strongly linear correlation between the op-amp GBW and the maximum
stable LED slew rate possible.  I found this originally when I built my
very first driver prototype with a 4 GHz GBW op-amp and compared it to
another LED driver I had on-hand that used a 90 MHz GBW op-amp.



I found that the maximum LED frequency the 90 MHz op-amp could achieve on a
1A shorted load was 100 kHz while the maximum frequency on the 4 GHz op-amp
driver with the same load was a bit over 4 MHz, showing a proportional
relationship (note the PCB layout on between these drivers is VERY
different).

4 GHz op-amp frequency response (200 kHz to 2 MHz): https://bit.ly/3g0GGiR

90 MHz op-amp frequency response (200 kHz to 2 MHz): https://bit.ly/37s2hwE

The fact that the 1.6 GHz op-amp performs about half as fast as the crudely
designed 4 GHz prototype driver, despite also being an entirely different
layout, seems to further confirm that the GBW of the opamp really is the
bottleneck in terms of maximum stable LED speed.  My hand waving
rationalization of this is that there is a highly non-linear relationship
between the op-amp output current and the LED current.  Therefore, if you
took the Fourier transform of the op-amp output you would find it requires
far more bandwidth to keep the non-linearity of the mosfet in check (think
of it as a simple convolution of LED current response and the mosfet gate’s
nonlinear response).  Therefore, getting a more linear mosfet would help a
bit (and spice simulations confirm this with slight improvements), but
speeding up the op-amp (specifically the GBW, not the V/s) is the surest
way to get a proportional speed boost.

Cheers,

   Ben Smith

On Wed, Dec 2, 2020 at 8:38 PM Benjamin Smith <[hidden email]>
wrote:

> Sure.  Here is what was written on my side off-list that may be helpful:
>
> *Current sense voltage choice:*
>
>
> In regards to using 5V driving voltage on the original driver, and a 3.3V
> driving voltage on the current driver, is for three reasons: 1) I've found
> I can get faster slew rates the larger the voltage step, 2) small voltage
> steps tended to also have a long phase delay with mV steps taking almost
> 100 µs, and 3) it gave us wider dynamic range since there is a limit to the
> noise floor on an op-amp, and therefore the only way to really increase the
> analog dynamic range is by increasing the maximum voltage.
>
> One thing that could possibly fix this issue would be to have a tunable
> negative input voltage and tunable negative op-amp rail for turning the LED
> off.  As it sounds like you also found, due to the input offset voltage,
> sending 0V to the op-amp actually leaves the LED dimly on, therefore you
> need a slight negative voltage to turn the LED off.   The catch is that
> this means I need to both send a small negative voltage to the
> non-inverting input on the op-amp, as well as have the negative side of the
> op-amp on a negative voltage so that it can safely handle the negative
> voltage input.
>
>
>
> That said, I think I just had a duh moment, the op-amp can handle up to a
> 0.7V differential on the inputs.  Therefore, the op-amp could very likely
> be powered with a 0-12V supply with a small negative input voltage (the
> current negative input is -0.25V).  This would help resolve a slight phase
> delay the driver currently has, where it has to swing the gate all the way
> from -1.8V to around 3-4V before the LED even begins to turn on.
> Therefore, reducing that swing to 0-4V would speed things up.
>
> With that in mind - if you could find a compatible 5V mosfet with a
> sufficiently low gate charge and a low resistance current sense resistor,
> you should be able to get up to  almost 10 MHz with this op-amp:
> https://www.digikey.com/en/products/detail/analog-devices-inc/LTC6268IS6-10-TRMPBF/5253537
>
> The op-amp still has the same output current, so the speed up would likely
> need to be paired with a DFN mosfet to get the gate charge low enough.  I
> used this op-amp in the very, very first draft (before I knew much about
> anything circuit design) and it was very fast, but it can be hard to find a
> good mosfet to pair it with.  Along those lines the LT6200-10's 12V range
> opens up a much wider range of available mosfets (as most of the good ones
> are fully open at 10V), so maybe the speed penalty is worth the versatility?
>
>
>
> *Unplanned destructive testing of mosfets:*
>
>
>
> "For early power tests I used to keep a finger on the tab of the MOSFET
> in case the temperature rose too quickly. "
>
>
> I wish I had this foresight in the previous design.  In that design the
> mosfet was buried between a header and the heatsink, and so was
> unreachable.  I originally tested the 1A version using a shorted output to
> prevent accidentally blowing out an LED if I did something stupid (it's
> also nice to not have a 1A LED shining at you while troubleshooting).  I
> then had a total brain-fart, and tested the 20A version also with a short.
> The end result being that my poor DFN mosfet got hit with 80W with only a
> 1oz/ft copper pad to a 40x40mm heatsink to cool it.  The fact it survived
> as long as it did (about 20 seconds) before it finally gave up the magic
> smoke is a testament to just how good that chip really was.  That said,
> with the current driver design the mosfet temperature rose only 10°C under
> 12W of heating, so it definitely looks like the goal of making a more
> thermally resilient driver for high current applications has definitely
> been achieved!
>
>
>
> And thanks for the insight on the die mosfets.  I couldn't find any good
> whitepapers on how to use them, which it sounds like I correctly took as
> them not being beginner friendly.
>
>
> *Wire inductance:*
>
>
>
> With the 20A driver, I used the classic wire loop connected to an
> oscilloscope to sniff out any EMI from the driver.  The driver itself was
> enclosed in an aluminum box with Faraday fan guards, so nothing was leaking
> out of that, however even outside the box the biggest source of EMI was
> still the SEPIC converters despite liberal use of grounded guard traces,
> ferrite beads, and shielded inductors.  The driver circuit itself had a
> little bit of EMI, but I guess thanks to careful grounding to minimize
> inductance, it was pretty negligible (that and the bandwidth of the LED is
> MUCH lower than the bandwidth of a SEPIC converter).  The other major
> source was the LED.  This makes sense as there is an appreciable gap
> between leads on a COB LED (relative to twisted enamel wire at least), so
> the LED itself had by far the strongest EMI emission.  It was also a pretty
> cool confirmation of just how low the inductance is in an enamel wire
> twisted pair that even with a 20A 1 MHz wave being transmitted through
> them, there was virtually no EMI being radiated (and the little bit that
> was radiated is far more likely from the resistance of the 12 AWG wire than
> the inductance).
>
>
>
> *Impedance matching:*
>
>
>
> Your insights on this match my own.  I played around with impedance
> matching in the SPICE simulation, but it was very specific to the wire
> used, and so people would need a different impedance setups for each wire
> choice (such as twisted pair, enamel twisted pair, CAT5, BNC, straight pair
> such as on the Thorlabs LEDs).  On top of that, the impedance of the COB
> LED is much higher than the wire, so you would also need an impedance match
> on the LED end of the wire as well.  By that point even I would never want
> to put such as setup together, let alone design one.  The impedance was
> also affected by bandwidth making the issue even more complicated.  Thus,
> adjusting the op-amp compensation instead proved to be a MUCH simpler
> one-size-fits-all solution with pretty much the same performance as
> impedance matching.
>
>
>
>
>
> *That's between Drain and Teensy, yes?*
>
>
>
> Yep.  The drain has four connections total.  One connection is to the 200
> Ohm resistor, with the Teensy ADC and the RJ45 connection on the other side
> of the resistor.  Another connection, of course, is the current sense
> resistors.  The third connection is a trimpot that connects back to the
> inverting input on the op-amp for adjustable compensation.  The fourth
> connection is a TVS diode that bridges the source and drain of the mosfet.
> The mosfet can handle up to 100V, so the TVS diode fully conducts at 97V.
> This is really only needed for rare edge case of high current and high
> voltage applications with long wires, but it also just makes me feel better
> knowing it is there.
>
> In regards to the series resistor, people have found that they did not see
> any attenuation on the bandwidth of the ADC with a 10k series resistor.
> The reason for choosing 200 ohms is simply because I already need two 200
> ohm resistors for the voltage divider to make the -0.25V input for the
> opamp, and so I already had two spare 200 ohm resistors on the 4x 200 ohm
> resistor array.  As 200 ohms was already more than enough for what I
> needed, I used that.  The fourth 200 ohm resistor was used as series
> resistor for a 0-3.3V clamp on the direct RJ45 to op-amp connection to at
> least try to protect the Teensy and driver from being over-driven (it
> protects only at +6V to -3V, so not much protection but at least will save
> the driver if connected to a 5V TTL signal).
>
> "I chose top not connect an ADC there, partly because I trusted the
> electronics to do it's job, partly because at that voltage it wouldn't
> really tell me that much anyway, partly because I had only so may ADC
> inputs to go around. "
>
>
>
> The original driver didn't have this connection for the same reasons (the
> Arduino only has 6 analog pins at 250 kHz), and instead only had a header
> connection for externally monitoring what the LED was doing with an
> oscilloscope.  The main motivation for the connection in this driver is
> since it requires  seeing the LED waveform to adjust the compensation, I
> wanted a way for people to use the driver even if they didn't have an
> oscilloscope.  On top of this, the Teensy has two internal ADCs multiplexed
> to 20 pins, so there is a plethora to choose from.  And on top of that
> since the ADCs support DMA, they can run at 1.1 MS/s, which is good enough
> for tuning the driver.
>
> As an added bonus, this same "calibration" window in the GUI allows the
> user to quickly confirm that the LED and driver are working correctly at
> the start of an experiment, which is especially helpful for fully enclosed
> LED setups.
>
> "Presumably Cat5/Cat6  STP would be quite good then."
>
>
>
> In one of my setups I used CAT5 instead of the twisted enamel wire out of
> convenience, and it proved to be as fast if not just a hair faster than
> enamel wire.  That said, it was also used to drive a diode laser, so that
> may also have been part of it.  Either way, that, and the discovery that
> thanks to security cameras you can buy CAT5 to BNC baluns for super cheap),
> was the motivation to switch the design fully over to CAT5 both for the
> LEDs and I/O connections.  The 4x RJ45 connecter also has a WAY smaller
> footprint and far lower cost than the equivalent 16 coaxial connections.
>
>
> *Summary:*
>
>
>
> I can say, for my side of things, I am hoping to have a driver design that
> is sufficiently easy to assemble and use, that there would be a low barrier
> to people building their own drivers for their research.  For example, in
> the assembly guide I am going to write (similar to this one:
> https://github.com/Llamero/Light_Color_and_Intensity_Datalogger/blob/master/Data%20logger%20assembly%20manual.pdf).
> One of the biggest hurdles I think will be to convince people how
> ridiculously easy reflow soldering is.  Before this project I had only hand
> soldered, and had this mindset that reflow soldering was super complicated
> elite level stuff.  I watched many videos and still was nervous.  Then,
> when I built my first driver, I realized that reflow soldering is insanely
> easy and takes absolutely no skill compared to hand-soldering.  If you can
> spackle a hole in a wall, you can reflow solder.  All the design work is
> already done (especially getting a circuit of this complexity routed onto a
> 1-layer PCB), so all a user needs to do is stencil on some paste, place the
> parts, toss it on a hot plate, upload the code, and voila you have a fancy
> new driver!
>
>
> Ease of assembly is also why there are no through-hole components, or
> parts that need to be hand soldered on.  The driver board is also 100 mm x
> 100 mm, which allows it to fit perfectly inside a standard project box
> without needing to wire connections.  Therefore, you only need to drill out
> holes for the pushbuttons, pot, switch, and back connections and you have
> an enclosed driver - no wiring needed whatsoever!  That and PCBWay prices
> metal core PCBs in a stepwise manner, so boards below 100 mm x 100 mm are
> all priced the same, so that became a fixed working constraint (hence why
> space is used fairly efficiently).
>
> Other than the lack of any hand soldering or wiring for the driver, and
> the use of the Teensy which is easily programmable, the other thing I
> really like about the current driver is that it is on a metal core PCB.
> This not only allows thermal management to be done in the 3D dimension, but
> also makes for a spectacular ground plane (especially in high current
> applications).  I did a lot of research on galvanic corrosion to make sure
> using the aluminum itself as a grounding plane would be safe, and from what
> I read it will be perfectly fine in a laboratory setting, and outside of
> that, there is a coating you can buy at the hardware store for $6 if you
> are going to use the LED driver outdoors for some reason.  That said, using
> the aluminum as a ground plane is not essential (the top layer has a
> low-inductance continuous ground plan on its own), so in cases where
> grounding to the aluminum may prove problematic, you can just use nylon
> standoffs).
>
> On Wed, Dec 2, 2020 at 8:17 PM Michael S. Nelson <[hidden email]>
> wrote:
>
>> *****
>> To join, leave or search the confocal microscopy listserv, go to:
>> http://lists.umn.edu/cgi-bin/wa?A0=confocalmicroscopy
>> Post images on http://www.imgur.com and include the link in your posting.
>> *****
>>
>> "I'm just wondering how useful this is to others on the list. It isn't
>> hard to delete for those not interested, but I wonder if we should add a
>> subject tag or if people would prefer us elsewhere. "
>> Hi Gordon,
>>   I, for one, have no *immediate *use for this information, but I think it
>> will be an *amazing* resource in the near future when I start getting my
>> hands dirty with microscope design. Having a record of all of this is
>> fantastic, though if you really wanted to take it to the microscopy forum,
>> that might also be another option where those interested might find it in
>> the future (or present).
>> https://forum.microlist.org/
>>
>> Cheers,
>> Mike
>>
>> On Sun, Nov 29, 2020 at 10:23 AM Gordon Scott <[hidden email]>
>> wrote:
>>
>> > *****
>> > To join, leave or search the confocal microscopy listserv, go to:
>> > http://lists.umn.edu/cgi-bin/wa?A0=confocalmicroscopy
>> > Post images on http://www.imgur.com and include the link in your
>> posting.
>> > *****
>> >
>> > Hi Ben,
>> >
>> > I'm just wondering how useful this is to others on the list. It isn't
>> > hard to delete for those not interested, but I wonder if we should add a
>> > subject tag or if people would prefer us elsewhere.
>> >
>> > Perhaps someone with a strong opinion will let us know.  Being here does
>> > make the project visible!
>> >
>> > On 27/11/2020 20:17, Benjamin Smith wrote:
>> > >   I've just gotten used to just dividing the values
>> > > by 10 in my head when using a 1x probe.
>> >
>> > I guessed, but it's always better to be sure.
>> >
>> > > As such, the 1A driver had a 5 Ohm
>> > > current sense resistor, and so a 5V output (50V on the oscilloscope)
>> > > corresponded to a 1A current.
>> >
>> > I wonder rather if the amount of swing on the source contributes to the
>> > dynamics issues.  Whilst the situation is different, I used 50mR for the
>> > whole range to 10A, so the voltage signal across the resistor never
>> > exceeds 500mV.  Similarly and trickier in the the OpenSource driver
>> > situation, I kept the anode voltage on the LED about a volt above the
>> > LED's maximum operation voltage, so the swing on the drain of the MOSFET
>> > is also only around 500mV.  I monitored Voltage and temperature with the
>> > uP, in both cases via suitable R/C networks that also gave over-voltage
>> > protection.  With 50mR sense, I was still able to keep the accuracy I
>> > then wanted (~0.1% of FSD, so better than 1% for all real currents).  I
>> > had to do a little fiddling at 0A to avoid any light from LEDs when
>> > they're supposed to be off, whilst also keeping the OPA in a linear
>> > state.  I probably can't say exactly what I did other than, as the
>> > MOSFET must be able to sink a little current in that condition and that
>> > current can't go through the LED, I arranged for it to go elsewhere.
>> >
>> > Low voltage swing on the Drain reduces the impact of Qdg as well as the
>> > dissipation of the MOSFET.
>> >
>> > > ... if a user accidentally shorts the current sense voltage, then
>> > > the op-amp will fully close the MOSFET which will instantly destroy
>> the
>> > > LED,
>> >
>> > For early power tests I used to keep a finger on the tab of the MOSFET
>> > in case the temperature rose too quickly. One day I switched on a
>> > prototype like that and within a second I had switched off again. taken
>> > my finger of of the MOSFET and yelped. Wow that was quick.  Everything
>> > survived. :-)
>> >
>> > >   and 2) the Teensy is also connected to the current sense voltage, so
>> > > if the Teensy pin was accidentally set to ground, you would also
>> > instantly
>> > > fry the Teensy.
>> >
>> > I chose top not connect an ADC there, partly because I trusted the
>> > electronics to do it's job, partly because at that voltage it wouldn't
>> > really tell me that much anyway, partly because I had only so may ADC
>> > inputs to go around.
>> >
>> > > Given the very high impedance of both the Teensy ADC and
>> > > most oscilloscopes, the impedance of the 200 ohm resistor is
>> negligible
>> > in
>> > > the low MHz regime.
>> >
>> > That's between Drain and Teensy, yes?
>> >
>> > >
>> > > One interesting thing you'll find in the SPICE model, and I've also
>> > > verified in real life, is that as long as you use a transmission line
>> > with
>> > > a constant impedance (such as the magnet wire twisted pair or CAT5
>> cable)
>> > > then the length of the wire - within reasonable limits - only
>> > contributes a
>> > > small phase delay rather than decreasing the slew rate.  In hindsight
>> > this
>> > > made sense, as you are basically sending a high power wave down the
>> wire,
>> > > and therefore the slew rate of the wave-front becomes self propagating
>> > once
>> > > coupled into the wire.
>> >
>> > Indeed ... ideally it should be a properly matched transmission line,
>> > though that's sometimes easier said than achieved. Especially with a
>> > variety of LEDs.
>> >
>> > > If your wire was REALLY long you definitely would
>> > > start running into dispersion and attenuation, but in my experience
>> the
>> > > difference between a 10 cm wire and a 3 m wire is practically
>> > nonexistent.
>> >
>> > Ah, OK.  I'd gained the impression earlier that the lead inductance was
>> > a big issue, but that suggests rather less so.
>> >
>> > > The other reason we use wires is that 1) it makes it much easier to
>> > > integrate to existing LED setups, and 2) it allows the driver to be
>> > farther
>> > > away from the microscope, which definitely helps when doing
>> > > electrophysiology, where you don't want to touch anything on or near
>> the
>> > > microscope (hence one of the motivations for the GUI as well).
>> >
>> > Electrophysiology was the term I couldn't remember.  I'm not a
>> > microscopist and not familiar with the constraints. It's interesting to
>> > me that twisted pair is suitable. Presumably Cat5/Cat6  STP would be
>> > quite good then.  I never heard of any complaints about the only
>> > long-leaded product I did, but the cable was shielded and we used
>> > twisted pairs within it.
>> >
>> > > That said,
>> > > I have fantasized time to time about the speeds I could get with an
>> LED
>> > > soldered directly onto the board.  Not practical, but it would be
>> really
>> > > cool to see what the upper limit truly is.
>> >
>> > Well, it needs only the OpAmp/Sink circuit and sufficient(!) local
>> > decoupling at the LED. Getting control signals down a transmission line
>> > would be easier and more predictable.  Perhaps now for another day,
>> though.
>> >
>> > >
>> > > In regards to the slow DPAKs, one thing I've found pretty consistent
>> > after
>> > > reading hundreds of data sheets is that any leads greatly slow down a
>> > > device, and the longer the lead - the greater the slow down.  I'd
>> imagine
>> > > parasitic induction is the largest culprit, as there is a pretty big
>> > > inductive loop under the lead (especially when you also factor in the
>> > wire
>> > > connected to that lead inside the epoxy package).  The resistance of
>> the
>> > > lead will also create an RC filter, especially on something with a
>> fair
>> > > amount of capacitance such as a MOSFET.  Along these lines, you will
>> find
>> > > that through-hole mosfets are by far the slowest, followed by leaded
>> SMD
>> > > packages such as the DPAK.  DFN packages tend to have pretty nice
>> specs
>> > > (this is what I used on the original driver) but as stated before, the
>> > > custom footprints kind of lock you in to a specific mosfet, and they
>> > don't
>> > > handle as much current and wattage as a DPAK package.  Then, if you
>> > really
>> > > want to drool, you should check out the specs on bare die mosfets:
>> > > https://www.digikey.com/short/zvqnpz.  Those things are insanely fast
>> > with
>> > > almost no Rds On and no gate charge, but the footprints are all
>> > different,
>> > > and I imagine they would pretty hard for an inexperienced person to
>> > > solder.
>> >
>> > Bare die are not for DIY. Getting the die down onto a substrate isn't so
>> > difficult, but wire-bonding is not a DIY task.  That said, with a
>> > suitable machine it isn't hard, either.  It was how that ex-employer was
>> > able to produce LEDs that we could run at, for the time, silly
>> > currents.  Bare die, straight onto substantial copper slugs and then
>> > onto more conventional heatsinks.  My guess is they now mostly(?) use
>> > pre-packaged LEDs. Today one can almost buy high-powered, wavelength
>> > specified, LEDs at the local store.
>> >
>> > There are lots of MOSFETs on a pretty standard SO-8-like thermal package
>> > and they seem to be consistently faster and have a lower Rdson that
>> > DPAKs.  They may well be 'twitchy'; I believe most are aimed primarily
>> > at SMPSUs.  I can't offhand remember if I ever used them for the sink
>> > MOSFET.  I think I may have used them only in SMPSUs.  Most of the 8-pin
>> > SO-8-like DFN packs seem to be pretty compatible.  Often  around 1mR
>> > Rdson, Vgs 2.5V logic-driveable. Ultra-low Rdson is only really
>> > significant for switching, so long as it's low enough to allow the
>> > device to stay linear with a low voltage across it.
>> >
>> > > That said, for a more advanced user, they could simply replace the
>> > > mosfet footprint in the KiCAD model, and build a driver that could go
>> > into
>> > > the 10s of MHz if the LED was mounted directly onto the board.
>> >
>> > I would think so.  Precision was fall, but my guess is that, provided it
>> > was clean and repeatable, precision would be a minor issue.
>> >
>> >
>> > > As far as monitoring the optical output waveform, I've used an even
>> more
>> > > cobbled together
>> >
>> > :-) .. Oh I doubt it ... mine was simply a photodiode and resistor
>> > straight onto the scope probe.  I'd trust the general impression, but
>> > nothing more.  On a plus side, it should have been as fast as my scope
>> > can do, which is 70MHz.  With the kind of light-levels I had, there was
>> > no problem needing amplification.  I simply declined to believe
>> > linearity.  All I was looking for, really, was propagation delay.
>> > Someone else checked the linearity of the light output and, where
>> > feasible, I applied a quadratic to correct the curve.  Most of my
>> > photosensor experience is at the low light end of the scale and with
>> > pretty slow signals.
>> >
>> > > Moral of the story, as long as you keep your LEDs
>> > > at a constant temperature, the current can very accurately predict the
>> > > output.  Modern LEDs are truly amazing!
>> >
>> > In an early model we used a Peltier to keep the temperature very
>> > stable.  Back then, I'm not sure how aware people were of some of the
>> > temperature and current.  We certainly had only the knowledge and our
>> > own experiments for the LEDs we were using. I don't recall the figures
>> > being published anywhere, though they may have been.  In truth I think
>> > temperature doesn't normally need to be all _that_ stable, provided it's
>> > kept inside a moderate range. Your massive heat-pipe cooler should do
>> > that well.
>> >
>> > Yes, modern LEDs _are_ amazing.  That's probably packaging and
>> > understanding more than anything, though there have certainly been some
>> > interesting breakthroughs at the die level and I presume at the
>> > chemistry level.  It's one of the reasons I've loved electronics all
>> > through my career.  It's a bit like climbing and false summits, except
>> > that each new 'summit' summit is normally "Wow!  will you look at
>> > that!", let's go there!  Frustratingly, there appear too many such
>> > summits for just one life.
>> >
>> > BTW, I'm not suggesting in any way that we "throw everything up in the
>> > air and start over".  Maybe some tweaks, maybe not. We learn and we can
>> > put different things into future incarnations.
>> >
>> > Kind regards,
>> >                       Gordon.
>> >
>>
>
>
> --
> Benjamin E. Smith, Ph. D.
> Imaging Specialist, Vision Science
> University of California, Berkeley
> 195 Life Sciences Addition
> Berkeley, CA  94720-3200
> Tel  [phone]
> Fax [phone]
> e-mail: [hidden email]
>
> https://vision.berkeley.edu/faculty/core-grants-nei/core-grant-microscopic-imaging/
>

--
Benjamin E. Smith, Ph. D.
Imaging Specialist, Vision Science
University of California, Berkeley
195 Life Sciences Addition
Berkeley, CA  94720-3200
Tel  [phone]
Fax [phone]
e-mail: [hidden email]
https://vision.berkeley.edu/faculty/core-grants-nei/core-grant-microscopic-imaging/