Optomotor module - How to increase the light intensity and pulse frequency

[ThHoler]

Hello,

We are using your ethoscope and optomotor module for optogenetics experiments, trying to trigger a Chrimson channel by pulsing 620nm LEDs.

However our first tests didn't show the expected results. There doesn't appear to be any difference in behavior between our control groups and our experimental groups.

Looking at the literature, it appears other teams achieved proper Chrimson activation with a similar wavelength, but much higher light intensity : we measured between 6 and 9 W/m2 at the end of the optic fibers, while we could mostly find values of at least 50 W/m2 in the literature. According to Klapoetke, Murata, Kim et al. "Independent optical excitation of distinct neural populations" (2014), who first described Chrimson, an intensity of at least 15W/m2 seems to be necessary to activate the channel.

As a result, we assume the intensity currently being delivered to our flies is too low to activate the channel. Is it possible to increase the light intensity emitted by the LEDs, and if yes, how should we proceed ?

We also would like to deliver shorter, more frequent pulses. At the moment, our interval parameter is set at 1s and our pulse duration at 700ms. We can't set the interval lower, and while we could go down to 500ms pulse duration, from our testing, it seems the pulses start being very unstable and become unsynchronized quickly. Is it possible to achieve lower pulse duration with higher frequency or is it limited by the hardware ?

[antortjim]

Your problem is similar to the one I faced, where I needed to provide more intensity (amperes) to the motors so they would reliable SD our flies. The solution I am trying and seems to totally solve the issue is using the new PCB @ggilestro has designed and posted for everyone here https://www.notion.so/Electronics-for-the-Ethoscope-modules-f39aebfe56b149d2bd828283ab43c538. The key lies in the usage of Darlington arrays, which can provide up to 500 mA, as opposed to the previous TLC5947 board we were using, which delivers up to 35mA. So you may want to change to this circuit and maybe get high power LEDs that can make use of this extra energy.

Regarding the frequency, I think that's given by Arduino, and I don't know what's the lowest

[ggilestro]

Dear @ThHoler - sorry for replying only now. This request escaped my attention.

I agree with @antortjim your problem is likely to be linked to the fact that you need more current to drive your LED. Difficult to say without knowing which LED you're using. You may want to check the datasheet of your LED for expected power. CRE LEDs are more powerful than regular LEDs.

Once you have the appropriate current feed there is no limitation on what you can do with that hardware but depending on what you need to do you may have to amend the arduino code.

[ThHoler]

@antortjim @ggilestro thank you for your comments.

Regarding the LEDs, we are currently using these : https://fr.rs-online.com/web/p/led/9047367
The idea of using the new PCB with the Darlington arrays could help, however the LEDs themselves wouldn't support that much current from what i understand. The data sheet mentions a forward current of 50 mA and a peak forward current at 200 mA for extremely short pulses. Do you have knowledge of more powerful through-hole LEDs or would we need to change the module to accommodate for a different kind of LED for more light intensity ?

As for the frequency, we solved the issue by bypassing the rPi control on the module and making it so that the Arduino board itself directly controls the LEDs. We are currently using 10 Hz with 50ms pulse width.
However it is not the most practical or elegant solution, but we have no idea how to achieve that same frequency using the rPi and the ethoscope code. When we tried to use the rPi to control the module, using the minimum settings (500ms pulse width, 1s rest), the pulses were very unstable, some LEDs would pulse at completely different rhythms. Could the frequency be limited by the fact that the OptomotorSleepDepriverSystematic class, despite not interacting with the behaviour in any way, is built upon classes that rely on behaviour analysis and thus requires more work from the rPi ?

ethoscope/src/ethoscope/stimulators/sleep_depriver_stimulators.py

Lines 347 to 397 in 0521648

	class OptomotorSleepDepriverSystematic(OptomotorSleepDepriver):
	_description = {"overview": "A stimulator to sleep deprive an animal using gear motors. See https://github.com/gilestrolab/ethoscope_hardware/tree/master/modules/gear_motor_sleep_depriver",
	"arguments": [
	{"type": "number", "min": 1, "max": 3600*12, "step":1, "name": "interval", "description": "The recurence of the stimulus","default":120},
	{"type": "number", "min": 500, "max": 10000 , "step": 50, "name": "pulse_duration", "description": "For how long to deliver the stimulus(ms)", "default": 1000},
	{"type": "number", "min": 0, "max": 3, "step": 1, "name": "stimulus_type", "description": "1 = opto, 2= moto", "default": 2},
	{"type": "date_range", "name": "date_range",
	"description": "A date and time range in which the device will perform (see http://tinyurl.com/jv7k826)",
	"default": ""}
	]}
	_HardwareInterfaceClass = OptoMotor
	_roi_to_channel_opto = {1:1, 3:3, 5:5, 7:7, 9:9,
	12:23, 14:21,16:19, 18:17, 20:15}
	_roi_to_channel_moto = {1:0, 3:2, 5:4, 7:6, 9:8,
	12:22, 14:20, 16:18, 18:16, 20:14}
	def __init__(self,
	hardware_connection,
	interval=120, # s
	pulse_duration = 1000, #ms
	stimulus_type = 2, # 1 = opto, 2= moto, 3 = both
	date_range=""
	):
	self._interval = interval *1000 # ms used internally
	super(OptomotorSleepDepriverSystematic, self).__init__(hardware_connection, 0,0,
	pulse_duration, stimulus_type,
	date_range)
	self._t0 = 0
	def _decide(self):
	roi_id = self._tracker._roi.idx
	try:
	channel = self._roi_to_channel[roi_id]
	except KeyError:
	return HasInteractedVariable(False), {}
	now = self._tracker.last_time_point + roi_id *100
	if now - self._t0 > self._interval:
	dic = {"channel": channel}
	dic["duration"] = self._pulse_duration
	self._t0 = now
	return HasInteractedVariable(True), dic
	return HasInteractedVariable(False), {}

[ggilestro]

You seem to be having two intercalating issues here. First of all, you would have to determine whether the LED you are using can potentially give you enough power to excite the flies. Are you using fiberoptics to bring the light directly inside the tube as we did in our PLoS Biology paper? If not, you should. These are the LEDs we used in our paper.

Regarding the piloting, the actual frequency should be driven by the arduino. The rPI can only instruct the Arduino on which frequency it should be using.

Finally: make sure your LEDs are NOT powered by the rPI USB port. The rPI USB can provide 250mA of current only and that is ok only for non-overlapping activation of LEDs.

[ggilestro]

Any news on this? Do you want to share an update? I believe other people may benefit.