Frequency-related lines commented out, so just temperature control left to work out. One happy camper 
Guys, last queries relating to temperature control: I’m planning a simple approach - once the temperature reaches a potentially damaging level I’ll dim the LED to a low level, then let it step back up to the requested level when the temperature recovers above another nominal value - ie I’ll have low and high temperature set levels.
Am I right to interpret that when the analog_read value from TEMP_PIN gets down to 265 (out of a range of 1023), that equates to 85 C, and that’s when you currently start applying dimming control ?
cheers
Hi Richard,
You are correct. Here’s a quick list of what values correspond to what temperatures:
% 60C: 443
% 70C: 355
% 80C: 293
% 90C: 235
% 100C: 184
% Slope: -7.5 steps per degree
We use a proportional temperature control approach so that the limit moves smoothly as the temperature becomes higher.
-Rusty
Rusty, you’re a star, that’s perfect. I’ll finalise the temperature control and then post the final version in here for anyone who’s interested, if that’s ok.
cheers, Rich
All working fine now, serial at 9600 baud direct into the yellow lead, 0-6 levels of dimming by sending characters “0”, “1”, “2” etc, frequency as you guys had it; I’ve added a temperature trip when it gets to 85 degrees, it flashes then drops down to level 1 until the temp comes down to 70 degrees when it resets to the prior level.
Code attached as text file for anyone who’s interested.
Thanks again for all the help, Rusty, very much appreciated.
LumenSerial.txt (3.6 KB)
2 Likes
Richard, that’s awesome! Nice work! I’m sure others may be interested in this.
Thanks for sticking with it and figuring out the issues!
Works with RS485 as well - connect D+ to black GND wire, connect D- to yellow wire, don’t connect the RS485 GND wire (if there is one). Haven’t tried it over any great distance yet, and I’m not sure whether this is an acceptable way to use half the 485 signal. But it works, so might be handy where there are cables longer than the RS232 limit (50m ish?).
…and just tested a pair of Lumens controlled in parallel - one RS232 channel controlling two lights; works fine.
4 Likes
I was thinking about the same sort of idea but would like I2C communications. This would allow each light to be addressable individually and bi-directional operation, you could check the state of each light; on, off, intensity, temperature etc. Also the lights could be daisy chained to the motors allowing only one penetrator for I2C and having the motors, lights, barometer and temperature sensors all on one bus. Unfortunately right now this would involve at least replacing the wire as there are only three conductors and I2C would need 4.
Cool thought. Could be done by adding a small board.
Hi,
My two cents: The electromagnetic noise created by the motors can interfere with the I2C with such big cables, I believe that RS485 is much more noise-resistant and better suitable for this use case.
I have three of the original thrusters with the embedded controllers that work over I2C. Is that going to be a problem for me? I agree, RS485 would be a better solution that was (is?) not an option. Since the thrusters, pressure transducer, temperature sensors all work on I2C (or should work) I was thinking the lights could as well. Keeping the number of penetrations of the container small is certainly a desirable situation.
Lawrence
Hi @rjehangir - I’m having some issues re-programming the new version of the Lumen to 232 control for a mate, are you able to share the orientation of the AVR-ISP pins on the new board ? I’d assumed it was the same, but I’m getting an “Invalid device signature” message, just want to check eg which pin is GND - cheers
Hi Richard,
The AVR ISP pins are the same on this board as the older one. Ground is right here:
If you’re having trouble communicating with it you might want to try powering the board with 12v while programming. Once the LED board is installed is doesn’t like to reprogram without power applied.
-Rusty
Perfect! Once again, thanks for the really prompt response, Rusty