jonnew/cyclops

Precision current source, with optional optical feedback, for driving LEDs and laser diodes

Cyclops LED Driver

Precision, wide-bandwidth current source with optional optical feedback mode for driving high-power LEDs and laser diodes. Good for sneaking optogenetic stimuli between fast things (e.g. galvo flyback on a 2P system). Good for really controlling the amount of light you deliver during 1P imaging or optogenetic stimulation.

If you have questions or comments, please come talk on the open-ephys slack in the #cyclops channel.

Features

• Ultra-precise
• High power
• Up to 1.5A per LED
• Wide bandwidth
  • ~2.5 MHz -3 dB bandwidth
  • Maximum 100 ns 1.0A rise and fall times
• Current and optical feedback modes
• Built-in waveform generation
• Over-current protection
• Modular
  • Arduino compatible: internal waveform generation
  • Also, accepts external analog, gate, or trigger inputs

Stimulus generation options

• External stimulus sequencer
• External digital trigger
  • TTL logic level
• External analog waveform generator
  • 0-5V analog signals
• Internal 12-bit DAC
  • Synchronized across up to 4 drivers
  • Arduino library
  • Programmable triggering logic
  • Respond to USB input

Buying one

You can purchase a fully assembled cyclops driver from the open-ephys store. All profits go towards continued operation of open-ephys.

Documentation

Documentation and usage information are here: MANUAL.pdf. If you have questions concerning usage, performance, etc., please direct them toward the Open Ephys forum.

Hardware Licensing

Copyright Jonathan P. Newman 2020.

This work is licensed under CC BY-NC-SA 4.0. To view a copy of this license, visit https://creativecommons.org/licenses/by-nc-sa/4.0

Note: This license applies to hardware designs and documentation which reside in the 'device', 'experimental', 'resources' folders of this repository along with information in 'MANUAL.md' and 'MANUAL.pdf'

Software Licensing

Copyright (c) Jonathan P. Newman 2017. All right reserved.

The code associated with the Cyclops project is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.

The code associated with the Cyclops project is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with this code. If not, see http://www.gnu.org/licenses/.

Note: This license applies to software/fireware source code which resides in in the 'lib' folder of this repository

cyclops's Issues

EMI shielding

The manual recommends the use of conductive coating for EMI suppression. Is this really necessary?

add Cyclops to open-neuroscience.com

Hello!

We are reaching out because we would love to have your project listed on Open Neuroscience, and also share information about this project:

Open Neuroscience is a community run project, where we are curating and highlighting open source projects related to neurosciences!

Briefly, we have a website where short descritptions about projects are listed, with links to the projects themselves, their authors, together with images and other links.

Once a new entry is made, we make a quick check for spam, and publish it.

Once published, we make people aware of the new entry by Twitter and a Facebook group.

To add information about their project, developers only need to fill out this form

In the form, people can add subfields and tags to their entries, so that projects are filterable and searchable on the website!

The reason why we have the form system is that it makes it open for everyone to contribute to the website and allows developers themselves to describe their projects!

Also, there are so many amazing projects coming out in Neurosciences that it would be impossible for us to keep track and log them all!

Please get in touch if you have any questions or would like to collaborate!

LED warming up time course issue

Hello!

I am currently using two Cyclops to deliver alternated pulsed light (8ms pulses) from 2 LEDs for imaging. I have noticed in my images a consistent artifact in the normalized fluorescence where it seems that a considerable number of frames start from very negative values. When checking the raw fluorescent traces in non-biological samples, it seems that the intensity of one of the LEDs progressively ramps up over the initial ~ 20 frames. The other LED shows an opposing trend, starting up higher and ramping down over a longer time span. Initially I figured it might be from the controller but when I checked in the oscilloscope, the output pulses seem to work fine. Image corresponds to an example of the fluorescent traces in a non biological sample, x axis represents frames, and y axis is normalized fluorescence.

With my limited knowledge about LEDs, I have figured out that at least the ramping down trend could be a junction temperature issue, but I still don't know if the ramping up behaviour is expected, if it can be fixed by compensating with the driver pulses, or if I should just replace the LED altogether. Has anyone observed a similar type of behaviour with their LEDs? Can this be fixed, perhaps compensating by tweaking the output from the driver in the initial frames, or should I just replace the LED altogether? In case this is an intrinsic LED thing, what would be the best way to correct this to minimize the contamination during real acquisition?

Thank you very much in advance and let me know if I can provide any further information!
Best,
Pol

PS: I am using the Luxeon Star LEDs from Quadica attached to a cylindrical aluminum heat sink with fins spanning the whole perimeter.

GUI - RPC Interface

A remote procedure call interface for the Cyclops Led driver for integration into the open-ephys software suite .

Prelim Report ::
Broadly settled on as to how to implement it and ways to further improve it.

Approach ::
• Given the use of the attached microcontroller primarily serving purpouses for Signal generation / feedback, any operation [ISR/LWP] that ran concurrently with the main thread / procedure must be extremely small.

//-Possible approach 1
• queue RPC`s on the client side and later transmit to the server when the server sends a "Free"/"Ready" State Signal. Doing this improves the precision of the output signal.
• In the case of a procedure having an infinite time of execution - bringing up the need for a terminate signal, a "Override"/ "accept next procedure “signal can be sent. since the serial TX is at the end of the procedure the precision of the signal is maintained.
• In order to implement the same, I could either modify the Serial ISR (finite/infinite time procedure) or check the number of waiting bytes in the serial buffer after each finite loop in an infinite time procedure.
• Could additionally take an execution time parameter and appropriately setup a timer interrupt / check, that returns to the parent.
• all procedures can be interleaved with breakpoints where (either the termination condition / ISR Terminate flag, is checked)

Issues/ Drawbacks::
• Sending the RPC after a "Free" signal increases latency. and a very small delay in the execution of the next RPC.
• Modifying the serial ISR May limit our maximum baud rate. (latency)
• Maintaining the queue on the client side is a small overhead.
• no way to soft reset the Arduino Micro controller in order to return to main.

ToDo::
• add parameters to the procedure call input,
• modify the ISR and setup flags,
• work out a neat system to introduce break points.
• Write queue software for the client side

WIP code for the ^^ will be updated to https://github.com/command-paul/cyclops shortly.

Get trigger input status in loop()

Hi Jon, I have a question. I want to have a pulse train going as long as the TRIG input is HIGH. I've tried doing this by using set_trigger to attach a function that starts the pulse train on the rising edge and another function that stops the pulse train on the falling edge. This didn't work out for me. I could only get one of the two functions to work, never both. And it doesn't seem like a very good way of doing this because I want to have the pulse train going as long as the trigger input is high (which varies from trail to trial). Is there a way to simply get whether the trigger is high or low in the loop() section?

Waveform Scheduler is not precise [Cyclops rev3.6]

This affects only Teensy 3.2
The Teensy loses time while in the ISR, while the code (and design) assumed that this loss would be negligible. But, tests with an oscilloscope have confirmed that the loss is significant ~20usec on avg. per ISR.

The only solution is to apply a compensation in the scheduling of "the-coming-ISR". IMO, any design would require a compensation of this sort.

A portable solution is to Measure time spent in ISR using another Timer and compensate. This is better than hardcoding time spent in interrupts, because time depends on the clock speed (Teensy's clock speed can be changed easily!).

Can't trigger my Cyclops

Hi Jon,

I'm Mathias from RWTH Aachen, Germany. We just bought 2 of the new (already assembled) Cyclops 3.6 with tennsy 3.2 installed.
I worked in the past already with the old Cyclops with an arduino Leonardo and was quite happy with it.
But now I have a problem with the trigger.
I installed the recent version of the arduino IDE 1.8.5, installed the add on to program the teensy and the recent Cyclops library.
I loaded the trigger_pulse example to the teensy without a problem and set the feedback loop to current. I tried to trigger the Cyclops over the trig bnc port with a 5v spuare puls but nothing happens. I maked sure that the LED worked fine. I tried another example like chirp and it worked flawless. I have this problem on both Cyclops so i guess it's not a hardware problem.
I read already all documentation i could find but didn't found a solution.
I hope you can help me out with this.
I'm looking forward to here from you.

Greetings from Germany

Mathias

TRIG Pin Driving Capacitive Loads

There is a very nice automatic, bidirectional logic-level translator on the TRIG path that virtually ensures a user will not destroy the MCU due to incorrect logic level choice to the TRIG input. However, this device is very bad a driving capacitive loads and will go into an unstable oscillation if, e.g., a long coax is put on the TRIG BNC port when it is used as an output. May need to think of how to buffer the TRIG output when its used to send pulses rather than receive them.

Buffering may not even be necessary -- a series 100 Ohm resistor to decouple the output pin of the ADG3301 from the capacitance of the Coax will probably work in most circumstances at the cost of a slower rise time due to effective RC.

USB port on Cyclops betas

Hi!
I have two cyclops kits and both are lacking the usb input port on the board. Do I need to install that myself? If so, I missed any reference to specs on what to use, do you have a recommendation?

Thanks!
Rebecca

Overcurrent indicator always on

I just assembled a Cyclops. The overcurrent indicator light turns on as soon as the module receives power and stays on indefinitely. I haven't tried hooking it up to an LED yet. Any idea what could be wrong?

Porting Cyclops to Teensy [32b MCU]

Teensy is a powerful microcontroller development system built on the ARM Cortex Mx architecture. It can be programmed via USB using the Teensyduino plugin on the Arduino IDE or the TeensyLoader application. With more hardware timers and DMA, the Teensy could provide lower latency in waveform updation and many more features like signal measurement and larger waveform storage.

Feature Comparison (with Arduino)

The table here (and here) from the Teensy main page summarises the major hardware features.

The Arduino Due has similar capabilities as the Teensy. They use the same Cortex M4 architecture but different manufacturer. Also, Due is programmed using the bossac toolchain whereas Teensy is programmed using the avr-gcc toolchain like all ATmega based Arduinos.

Feature	Teensy LC	Teensy 3.2	Arduino Uno [8b]	Arduino Mega [32b]
Processor	Cortex-M0+ (MKL26Z64VFT4)	Cortex-M4 (MK20DX256VLH7)	Atmega328	Atmega2560
Clock Speed	48MHz	upto 96MHz	16MHz	16MHz
Flash Mem	62kB	256kB	32kB	256kB
SRAM	8kB	64kB	2kB	8kB
EEPROM	?	2kB	1kB	4kB
DMA channels	4	16	0	0
ADC "inputs"	13	21	6	16
DAC "outputs"	1	1	0	0
Timers (of all kinds)	7	12	2	5
USART	3	4	1	3
SPI	2	2	1	1
I2C	2	2	1	1

Porting Effort

Teensy uses the avr-gcc toolchain and allows user to run Arduino Sketches through the Teensyduino plugin of Arduino IDE.
They have also documented steps to utilise the avr-gcc toolchain directly (baremetal Teensy development), without using the Arduino headers.
Teensyduino has a large collection of general purpose libraries.
Thus, we can choose to cherry-pick libraries that work without Arduino headers or work with Arduino compatible librarires.

Teensy References and Links

Teensy home page
TeensyLoader CLI
Teensy CPU datasheets, particularly the K20 family. All information on DMA was sourced from the K20 datasheet.

Typo in Cyclops.h comments

Small typo in Cyclops.h on line 140: CHANGED should be CHANGE

Power switch installation instructions

The power switch needs to be placed through the appropriate hole in the enclosure before being soldered to the PCB. The instructions should be updated to reflect this.

TRIG input remains at ~3V after receiving a single pulse

Hi John,

When we use an arduino digital output (or any other 5V trigger pulse for that matter) we run into the following issue: The cyclops is triggered once as expected (attached LED blinks) but then the voltage at the 'TRIG' BNC input remains at a level of 2.9-3V persistently. We were able to mitigate this somewhat by connecting the 'TRIG' bnc pin and shield with a 100 kOhm resistor to allow that voltage to dissipate but it's not ideal and really doesn't work at all when the trigger comes from a 3.3V arduino (e.g. due).

Do you have any idea where that residual voltage comes from and is there any way to zero it out in arduino software or otherwise?

Thanks a lot for your help!
Thomas

LED continuously on

Whenever I turn on my Cyclops, there's a baseline LED current that won't go away. I can still modulate the signal with the Ext input, but the power never dips below the baseline level.

It was working fine last week, and I can't figure out what might have changed. Any suggestions for troubleshooting?