Notices

Good thing, that I was fast enough to perform some ugly tests - I took one of my N900's, set insane duty cycle of 500 ms ON and 50 ms OFF, max power lvl (320 mA) - then left it running for ~10 hours (until battery run out, due to lower power - it was almost full dual-scud). Then, I repeated this step with power from charger, for 48 hours straight.

Results - no oddities in LED's working, no visible change in color temperature. They were just a little warm (just like after running torch mode for few hours).
---

Of course, it doesn't mean I don't agree with pichlo about safe limits etc. He is absolutely right. It's just that, from practice, manufacturers tend to put much more powerful LEDs, than their chips could drive - to avoid tons of free replacements during 2 years guaranty period. Our diodes are, probably (warning - just assumption, not based on anything) rated for at least 100 mA continuous current (if not even more), and torch being limited to 50 mA is effect of few independent layers of safety margins.

In Android world (where, I do agree, device safety isn't top priority, nor usual level of expertise), it's common practice to run camera leds at 2x or 4x "standard" current continuously, just after throwing a little warning. None of my sources ever reported any led damaged due to that (although, I must agree, at first I was very wary, too).

Heck, judging by (subjective observations, not measured by any scientific means) brightness level, Nokia's closed source camera application - in darkest environments - uses more current than this 320 mA upper limit. At least, it's flash seems brighter, than strobe produced by Lanterne on max power level. I wouldn't be surprised, if they would pump there that "unofficial" (in FOSS drivers) 500 mA max current.
---

This post isn't aimed at convincing anyone to risk own device safety - but, i think, that limiting duty cycle to 25% is a little too far. It would be silly, if Lanterne would have to get "fork" for every release ("LED Destroyer" sounds like a good name? ), with only one change being removal of safety limits. Not that it would be anything bad - just silly, a little.
---

Nevertheless, thanks for another bunch of great updates!

/Estel

Yes, the max 25% duty cycle may seem a bit conservative (and maybe not, if 15% really is better). But then, as I have said before, I'm not a hardware expert. I could certainly believe that the N900's LEDs could take a lot more than that, but I just don't want to take the risk; who knows if everyone's LEDs are the same strength? What if there is some cumulative effect that will reduce the lifespan of the LEDs?

But let me note something! You said:

Hey, now, if this was an Apple or Windows phone (and possibly even an Android phone), you would be justified in making that statement; in those worlds, only the "elite" have access to the phone's hardware. But this is an N900! The phone is yours to use, modify, and play with to your heart's desire. At the drop of a hat (and with no need to get approval from Nokia or any other corporation) you can write your own app (or modify the code of an open-source program like Lanterne) and do whatever you want. No NDAs to sign! No jailbreaking required! No alternate ROMs to install!

This is an open source world, man. The code is out there for you to examine, use, and modify to your heart's content. Go for it!

Hey, I didn't wanted it to sound "ungratefoollish" or anything like that. It was rather something like "it's good that I tested it before upgrading, as then, I wouldn't be able to test it without messing with source code". Which, probably, would mean I wouldn't test it at all - too many projects, too short day.

In fact, it's equally the opposite - when I first thrown a proposition for such program in Pierogi thread, it was less than 24 hours, before you released nicely working application. Now, few days later, it is feature-full all purpose solution, with addition of things like morse code and indicator led support. It's absolutely awesome rate of contributing!
---

Now, I think i might contribute a little (in fact, *very* little) addition to Lanterne. The thing is, that since few releases, kernel-power introduced a (optional) hack, to disable irritating auto-enabling of indicator LED, when video is recorded. The hack consist of:
...sysfs entry, where we echo 1 (prefferably, automagically, at device startup) to disable indicator LED. Sadly, even with camera-ui2 (cssu'ish one), it is only possible way to get rid of that LED, if we want to record videos using nokia's optimisations. (cssu'ish camera-ui offered toggle to switch indicator off during video recording, but it would still light up at beginning of video, with no way to prevent it).

The problem: disabling indicator LED is "for all intent and purposes", i.e., it won't work in Lanterne, too. Having to revert sysnode entry everytime I might need to use led torch that doesn't destroy night vision, doesn't match my aesthetic. OTOH, I didn't wanted to ask Copernicus to integrate disabling that sysnode on program startup - it would throw errors on non-kp devices (all two of them :P ), and add another layer of complication for program (like dropped idea of preventing camera to start).

So, I patched together a brain-dead wrapped around Lanterne executable, that (externally) clears sysfs entry on Lanterne startup, and enables it, when Lanterne exits. Of course, it also required modification of Lanterne's .desktop file, to run wrapper, instead of main bin. Messing with sysfs require elevated permissions, so we add sudoers file to the mix, and lanterne-helper is cooked.

It should allow to keep indicator OFF from messing with video recording, yet, allow its usage in Lanterne, automagically. It's downloadable from this post attachment.

Installation: (assuming tar got saved to /home/user/MyDocs/)
as root:
It should be compatible with all future Lanterne releases (unless executable location changes), but after every upgrade, Lanterne .desktop file will need to be modified (or replaced by one from this .tar) again.

Depending on your configuration, you may, or may not need to execute:
/Estel

// Edit

Speaking of camera-ui from cssu - using it, I noticed, that even if Lanterne is configured to use camera key to toggle LEDs, it does as intended for a split second, then, launch camera-ui anyway (disabling LED control for lanterne). Is it intended? I don't know if it does matter, but I use QuickLaunch application, for controlling, what happen when I open camera cover (mainly, due to it popping up 4-slot holder for programs, and 5th for custom command, on camera lens opening).

I've gotta admit, you've got me there; I didn't even know there would be a demand for something like Lanterne. I was able to more or less just throw bits and pieces of Pierogi (and a little of the other pasta products I've been cooking up) into an app in no time flat...

(I should ask, are there other little apps that you might find useful?)

Hmmmmmmm. Actually, if you run Lanterne and the Camera-UI at the same time, _both_ of them have access to the indicator LED. In short, Lanterne can not only switch on the LED, it could in theory suppress anyone else from switching on the LED... (At the very least by switching it off over and over, if nothing else.) Let me see what options there are.

Nope, it's not working the way I'd like at all. I am still pondering the vast mysteries of the camera key. It's used by so many different apps now in so many ways, I'm not sure I'll ever find a way to use it the way I wanted to...

I believe anyone with two N900s could run them in a dark room white a4 paper set distance say 500mm one phone as the LED emitter and one as the light meter to determine actual LED power for the Nokia app flash and the Lanterne settings.

i want to kill red led forever if possible

Joys of doing things late at night - I wrote everything, then, of course, forget to attach file. Fixed, lanterne-helper should be downloadable from quoted post attachments, now

Generally, such things comes out "in addition", like all-purpose flashlight solution, when you included remote flash in pierogi... But, from top of my head, there is for sure one thing that would be usefull for +- everyone, and IMO would result in even more oustanding feedback than Lanterne:

A good program for (automatically or manually) recording calls, system/bluetooth sound, etc! We have "recaller", but it's unmaintained, bugged as hell, tends to hang on worse possible moments, and half functions doesn't work as intended (FLAC recording fails silently, can't automatically record SIP conversations at all...) + It suffers from "I'm a widget" crippled configuration (still, some bits of it could be sueful to determine how to achieve certain things).

Having all the bad things about recaller said, I'm using it daily (and many other people too, AFAIK), so I would download properly maintained replacement in a heartbeat. Could be good reason for you to learn bits about N900 sound thingie's, too If you take the idea, you're my hero (even more than you're already ). No matter what, thanks for asking!

/Estel

// Edit

As for Lanterne itself, small idea, that I got after playing with it yesterday - some way of (separately) quick access to light up *either* normal torch or indicator one, would be great. In most cases, I use normal torch, but if, for night vision reasons, I need to use indicator, wenturing into settings and changing it, going back, and enabling,m already destroys NV due to looking at screen for so long.

I know separate ON/OFF button for torch and indicator may crowd main menu a little, but it seems most practical. Or some small "toggle" that would affect what is enabled by torch ON/OFF?

BTW, following status menu idea - status menu widget with two buttons (torch ON/OFF | Redlight. ON/OFF) would serve that purpose even better

/Estel

Bug report. After a fresh reboot, I started Lanterne and managed to get Morse code repeat the three words I had typed in continuously even though the option was off (witnessed by another human). I did mess with the Preferences before using Morse code, but other than that I don't know what might have caused it; I can't reproduce it now. Getting out of Morse code and clicking on the Morse code button stopped the transmission. The light was red (as chosen by me).

Ack, sorry, I didn't initialize the variable correctly. Thanks! I'll get a fix into the next release.

Feature request.
Any chance of an option to automatically switch on a mode at start-up?
I am thinking a checkbox to enable with a combobox with (Torch and Flash) options in.

This will then completely remove my need for Flashlight.