Will we ever see a true end-user-programmable UI?

[carrot]

Yes, thank you, I guess this strikes at the heart of my question. I kind of suspected the hardware was already adequate. So it's the software that is lacking.

But my goodness, I would think a programmable UI program would be pretty easy to write????

-

Not if you wanted it to also be easy to use.

 

[wyager]

The problem with RS232 is that you need components to handle voltage outside the processor range and that many of the small micros used in flashlights does not have the serial hardware.

I still believe that the best solution is I2C or or SPI with a few contact points in the head around around the battery plus pole connection.

The a cable with a USB-I2C or USB-SPI chip that can be connected instead of the battery, when the light has to be programmed.

This would not change the production cost of the light, the cable and PC software could be sold as an extra that would work with many lights from the same manufacturer.

Who said RS232? I simply said serial... the cheaply available PL2303 chip would work great and you can get it EVERYWHERE, you can get a cable for like $2 shipped on the internet, and you just splice the wires... it gives a safe 3.3v and can handle anywhere from ~2.4 volts to 5.5 volts IIRC. I2C or SPI would rob way too many clock cycles and is too hard to bitbang. Honestly, serial is RIGHT there and it takes like 3 or 4 lines of code to set up. It would also not change the production costs...

 

[HDS_Systems]

Chevy-SS,

There are several problems with a true end-user-programmable UI:

1) Expense.

Let's use your example of a USB computer interface. First, you need a bunch of extra hardware in the flashlight that most likely will rarely be used. Then you need a very flexible system for controlling the interface, which must take into account the interface hardware and all of the different ways you can interact with that interface. Then you need software on the PC that knows about all of the possible options. There will be a large expense in developing both. The development cost must be amortized over some number of flashlights and added to the cost of those flashlights.

Let's pretend it will take an engineer one year to develop and test everything - which is probably optimistic. Let's assume you pay that engineer $60,000 fully burdened - which may also be optimistic. If you plan on selling 1000 flashlights, the development costs will add $60 to each flashlight. You can use other assumptions to get other values.

2) Complexity.

Infinite configurability is infinite complexity. Have you ever defined a UI? Do you really expect your customer to design a UI? Even if you gave your customer 20 template UIs, it would be an uphill task to pick one and then get it configured.

When I laid out the UI for the HDS Systems clicky-style flashlights, it took a long time to work my way through all of the various possibilities and arrive at what we have today. Our UI supports 4 presets, each of which can be any of the 23 levels or 3 signals. Plus there are 6 global options. And that is just 1 possible UI design based on a single button. There are lots more possible UIs based on a single button and you will find many of them on different models of flashlights.

3) Market.

We did look at doing this a long time ago and decided the market was too small. There just were not enough people in the world interested in such a device to justify the effort.

There was a flashlight a few years ago that had a USB interface. I don't think it ever got into production as it was expensive for the utility it provided. It was designed to be very configurable, with a software UI, interchangeable LED modules and other parts. Jack of all trades, master of none. But is was a good attempt and seemed to work well.

Henry.

 

[HKJ]

Who said RS232? I simply said serial... the cheaply available PL2303 chip would work great and you can get it EVERYWHERE, you can get a cable for like $2 shipped on the internet, and you just splice the wires... it gives a safe 3.3v and can handle anywhere from ~2.4 volts to 5.5 volts IIRC. I2C or SPI would rob way too many clock cycles and is too hard to bitbang. Honestly, serial is RIGHT there and it takes like 3 or 4 lines of code to set up. It would also not change the production costs...

I have done both serial, I2C and SPI in software and I think serial is the worst, another problem is a micro running on a uncalibrated RC oscillator, you need to add code to automatic calibrate the baud rate.

The cpu load does not really matter, the interface and the flashlight does not need to be active simultaneous. Putting this chip in a cable and doing it as I described above would also be nearly cost neutral.

1) Expense.

Let's use your example of a USB computer interface. First, you need a bunch of extra hardware in the flashlight that most likely will rarely be used. Then you need a very flexible system for controlling the interface, which must take into account the interface hardware and all of the different ways you can interact with that interface. Then you need software on the PC that knows about all of the possible options. There will be a large expense in developing both. The development cost must be amortized over some number of flashlights and added to the cost of those flashlights.

Let's pretend it will take an engineer one year to develop and test everything - which is probably optimistic. Let's assume you pay that engineer $60,000 fully burdened - which may also be optimistic. If you plan on selling 1000 flashlights, the development costs will add $60 to each flashlight. You can use other assumptions to get other values.

Doing a full usb interface in a microprocessor might take some time, but doing it as I described above would not add any significant hardware cost. The development would take some time, but when looking back n the projects I have done with small microprocessors and PC configuration tools, it does not come anywhere near a year.

2) Complexity.

Infinite configurability is infinite complexity. Have you ever defined a UI? Do you really expect your customer to design a UI? Even if you gave your customer 20 template UIs, it would be an uphill task to pick one and then get it configured.

When I laid out the UI for the HDS Systems clicky-style flashlights, it took a long time to work my way through all of the various possibilities and arrive at what we have today. Our UI supports 4 presets, each of which can be any of the 23 levels or 3 signals. Plus there are 6 global options. And that is just 1 possible UI design based on a single button. There are lots more possible UIs based on a single button and you will find many of them on different models of flashlights.

A programmable does not need a multitude of different UI templates, look at something like the JetBeam IBS, it has different brightness settings and a collection of flashing settings. For a programmable flashlight add a variable number (1-9) of slots that can be programmed with something like that or for a ring light add a slot for each position on the ring.
Then add a few extra options (Like low battery shutoff, memory/no memory) and it would be a nice user programmable light.
No more complains about high or low first, memory or no memory, spread between brightness setting etc., flashing modes or not, all can be adjusted easily from a PC.

 

[wyager]

I have done both serial, I2C and SPI in software and I think serial is the worst, another problem is a micro running on a uncalibrated RC oscillator, you need to add code to automatic calibrate the baud rate.

WHAT? Lol, you MUST be doing something wrong... an oscillator is just fine for serial comms, especially at low speed. Considering the fact that the serial re-syncs after every byte, even like 15% error is OK.

The cpu load does not really matter, the interface and the flashlight does not need to be active simultaneous. Putting this chip in a cable and doing it as I described above would also be nearly cost neutral.

The goal here is to have as little power consumption as possible, which means as low speed as possible, which means I2C and SPI are hard to use. At 16khz on an AVR, you can easily get 2400 baud serial... You could probably bitbang it even faster. It's also cost neutral, and the cables are cheaper as well...

Doing a full usb interface in a microprocessor might take some time, but doing it as I described above would not add any significant hardware cost. The development would take some time, but when looking back n the projects I have done with small microprocessors and PC configuration tools, it does not come anywhere near a year.

I strongly disagree. To get USB you either have to install expensive, large, and power hungry PHYs or bitbang it, which requires diodes, resistors, crystals (or heavy modding that would not work here), and it's not super reliable or efficient. Serial is super duper easy and can be done cheaply and cables can be made on a hobbyist level, cheaply. Good luck finding a USB-I2C cable for under $3.

 

[HKJ]

WHAT? Lol, you MUST be doing something wrong... an oscillator is just fine for serial comms, especially at low speed. Considering the fact that the serial re-syncs after every byte, even like 15% error is OK.

A byte is 10 bits and you must only drift about 1/2 bit, you also need to leave some tolerance for the other side. That gives a tolerance of 2 to 3% witch is at the limit of a uncalibrated RC oscillator.
Speed does not enter the equations.

The goal here is to have as little power consumption as possible, which means as low speed as possible, which means I2C and SPI are hard to use. At 16khz on an AVR, you can easily get 2400 baud serial... You could probably bitbang it even faster. It's also cost neutral, and the cables are cheaper as well...

Flashlights does not run the processor at 16kHz, on many flashlights the pwm need considerable higher frequencies than that. You will need a custom cable, if you put the interface chip in the cable. Putting the chip in the flashlight will probably be a space problem!

I strongly disagree. To get USB you either have to install expensive, large, and power hungry PHYs or bitbang it, which requires diodes, resistors, crystals (or heavy modding that would not work here), and it's not super reliable or efficient. Serial is super duper easy and can be done cheaply and cables can be made on a hobbyist level, cheaply. Good luck finding a USB-I2C cable for under $3.

I would not do USB in the micro, I would use a dedicated USB-xxx chip in a cable to keep the cost of the flashlight down and simplify development.

 

[wyager]

1.A byte is 10 bits and you must only drift about 1/2 bit, you also need to leave some tolerance for the other side. That gives a tolerance of 2 to 3% witch is at the limit of a uncalibrated RC oscillator.
Speed does not enter the equations.

2.Flashlights does not run the processor at 16kHz, on many flashlights the pwm need considerable higher frequencies than that. You will need a custom cable, if you put the interface chip in the cable. Putting the chip in the flashlight will probably be a space problem!

3.I would not do USB in the micro, I would use a dedicated USB-xxx chip in a cable to keep the cost of the flashlight down and simplify development.

1. You would think so, right? Not only can I use an uncalibrated oscillator reliably up to 1MB/S, but at lower frequencies I don't even have to have an exact serial prescaler. And speed definitely enters into the equation, in that some speeds are more compatible with certain clock frequencies.
2.Umm, no... some flashlights do PWM at around 200 hertz, and while this is slow, 4khz is basically a limit with most drivers... at 16khz, an AVR can do 8khz PWM no problem. Probably too fast for some drivers. And with serial you don't need any special chips, just a cheap, common PL2303 that works on EVERY os with open-source drivers.
3.How about USB-serial, as I've been suggesting? For these purposes (non-time sensitive short distance small size data transfer) serial is just fine. If we were doing active measurement and communication I might use I2C or something but for this serial would be fine.

 

[HKJ]

1. You would think so, right? Not only can I use an uncalibrated oscillator reliably up to 1MB/S, but at lower frequencies I don't even have to have an exact serial prescaler. And speed definitely enters into the equation, in that some speeds are more compatible with certain clock frequencies.

It might work, but I would never use it in production, there I prefer to be within tolerances.
Yes, speed is significant when selecting setting up baudrate, but it is not significant for tolerances (Except you have to include your speed error in the tolerance calculations).

2.Umm, no... some flashlights do PWM at around 200 hertz, and while this is slow, 4khz is basically a limit with most drivers... at 16khz, an AVR can do 8khz PWM no problem. Probably too fast for some drivers. And with serial you don't need any special chips, just a cheap, common PL2303 that works on EVERY os with open-source drivers.

I have seen from 100 Hz pwm to 38 kHz pwm.
The frequency to the pwm generator needs to be 128 to 256 times the actual pwm frequency or you would not have any adjustment range (A few processors can multiply the clock frequency to the pwm generator allowing a low cpu clock).

3.How about USB-serial, as I've been suggesting? For these purposes (non-time sensitive short distance small size data transfer) serial is just fine. If we were doing active measurement and communication I might use I2C or something but for this serial would be fine.

If a manufacturer prefer to use serial, it is ok for me, I just believe that I2C/SPI is easier and safer (see above).

 

[longboat]

...
I still believe that the best solution is I2C or or SPI with a few contact points in the head around around the battery plus pole connection.
...

OK, here's the deal. You put the programmable IC chip in the pill, make it as small as is reliably possible, and connect up via those contact points you mention.

Now, here's the slick part...

Make a second flashlight body available as an accessory/option. This body would not need to be tough, robust, well-designed, anodized or any of the cool stuff we take for granted on quality flashlights. It simply needs to house the USB port and any needed programming doodads within its body, as well as room for the battery(s).

How it works: Simply remove the head from your quality flashlight body and place it on the accessory body, connect up to your PC with the standard USB cord, and program the UI. When finished, remove the programmed head and place it back onto the quality flashlight body and VOILA!, you are good to go.

So, why go to the trouble of having a whole other body? This way, you can have batteries installed and program the light output on the fly (WYSIWYG) rather than trying to guess what the output might be once you put the power back to the LED. The extra body shouldn't be too expensive to manufacture as it does not need to be a high-quality part (it will only be used in the comfy confines of your computer's environment).

 

[wyager]

1.It might work, but I would never use it in production, there I prefer to be within tolerances.
Yes, speed is significant when selecting setting up baudrate, but it is not significant for tolerances (Except you have to include your speed error in the tolerance calculations).




2.I have seen from 100 Hz pwm to 38 kHz pwm.
The frequency to the pwm generator needs to be 128 to 256 times the actual pwm frequency or you would not have any adjustment range (A few processors can multiply the clock frequency to the pwm generator allowing a low cpu clock).




3.If a manufacturer prefer to use serial, it is ok for me, I just believe that I2C/SPI is easier and safer (see above).

1.I see your point... I suppose you have to decide if you want reliability or simplicity/power savings.
2.not with the micros I use... Setting the duty cycle sets the trigger point of a comparator, which measures a triangle wave. This technique lets you have a PWM frequency at half the speed of the main clock...
3.I suppose that's valid... The main reason I disagree is that USB-spi cables are not plentiful or cheap.

 

[HKJ]

2.not with the micros I use... Setting the duty cycle sets the trigger point of a comparator, which measures a triangle wave. This technique lets you have a PWM frequency at half the speed of the main clock...

I have never seen a analogue pwm in a microprocessor, they are digital and need to count up/(down), that means to get 1% pwm you need the clock to the pwm to be (at least) 100 times the pwm frequency (1 count is high, 99 counts is low).

 

[jellydonut]

OK, hardware isn't a problem, software shouldn't be too big of an issue, what about the interface (between computer and flashlight)? Mini-USB has been mentioned, but that takes some space and can be problematic for waterproof standards.

I bring you the Sonim XP3 GSM mobile phone;



Rated to the IP57 and MIL 810 standards. And yes, I have tried it - it has been subjected to fresh water, salt water, strong detergents and various alkaline and acidic marine chemicals. It's fine.

Here's some (cheap!) electronics to ponder; http://www.arduino.cc/en/Guide/ArduinoMini

 

[lolzertank]

I think if there must be a connector, it should be in the head next to the positive battery contact. Having rubber covers is not the best idea considering that it might break off if the flashlight is dropped/thrown onto the ground.

Off the shelf interface cables aren't too expensive. FTDI's FT232 based cables are like $15, and I think they can be configured to do SPI. At the very least they can do TTL level RS232 (3 mBaud, plenty of bandwidth ). There are also various breakout boards for the FT232 chip itself that allow for different logic levels and such.

I still think the best solution is some type of optical transmission though. I should try that some day...

 

[jellydonut]

I've dropped and tossed the phone multiple times. Testers have thrown it around and ran it over with cars and trucks.

http://www.youtube.com/watch?v=YDkNC2WKYKc

Rubber plugs can be very durable.:naughty:

 

[wyager]

I have never seen a analogue pwm in a microprocessor, they are digital and need to count up/(down), that means to get 1% pwm you need the clock to the pwm to be (at least) 100 times the pwm frequency (1 count is high, 99 counts is low).

From atmel: The waveform
generated will have a maximum frequency of fOC0 = fclk_I/O/2 when OCR0A is set to zero. However, I think now that looking at it that might only apply to certain frequencies. Like 1/4 duty cycle can have a max frequency of 1/4 clock. They didn't make that clear.

 

[HKJ]

I still think the best solution is some type of optical transmission though. I should try that some day...

That would be nice, but it requires extra hardware in the flashlight.
It could either be standard IRDA or use the white power led in the flashlight as both transmitter and receiver, but this would require and external receiver/transmitter also.

From atmel: The waveform
generated will have a maximum frequency of fOC0 = fclk_I/O/2 when OCR0A is set to zero. However, I think now that looking at it that might only apply to certain frequencies. Like 1/4 duty cycle can have a max frequency of 1/4 clock. They didn't make that clear.

I have programmed pwm on AVR processors multiple times and most of them requires a much higher clock frequency than the pwm frequency (if you want to do some regulation with the pwm).

 

[mike.s]

Apparently no one in this discussion has heard/seen an AKOray K-106 or AK-16. 3 user programmable modes (chose from selectable brightness, strobe, or SOS), along with memory. You can set cell protection on/off, too. All using the clicky, and $20 cheap.

There's really no need for any kind of computer connection - unless you want to be able to flash out "Look at my kewl flashlight" in Morse code.

That's not saying the AKOray setting interface can't be improved upon, it definitely can. It's hard to set low levels, you can't set levels on flashing modes, and there's no beacon mode. But, that's just a matter of tweaking - the basic capability is there, and it works fine. Are there any useful modes I'm missing? Why would they require a computer connection to set them?

(and it doesn't take a second to boot, and it doesn't drain the battery when off)

 

[longboat]

Apparently no one in this discussion has heard/seen an AKOray K-106 or AK-16. 3 user programmable modes (chose from selectable brightness, strobe, or SOS), along with memory. You can set cell protection on/off, too. All using the clicky, and $20 cheap.
...

I think most everyone here is aware of most of the programmable flashlights that are available (LiteFlux LF2XT is a popular highly-programmable light mentioned frequently on this forum). Heck, just look at the fifth sticky from the top!

The point is that these lights are not easily or fully progammable for all of the different modes/memories that many users would want. As you've noticed with the AKOrays, and with the LiteFlux models, it can be difficult just to get the exact output you want, and the low may not be low enough as an example. We are just trying to get maximum flexibility out of these modern high-quality flashlights.

I myself would be extremely happy with a two-headed flashlight (thrower on one end, floody on the other end) with a super low (0.5L), medium (20L) and high (150L) for each head, pre-selectable by twisting the detented head/ring, configurable as a 1AA or 2AA (oh, and a 3C model for a baton light :naughty: ).

 

[mike.s]

In what way are those lights not "true end-user-programmable," which is what this thread asked for? Go back and read the original post - the OP asks for programmability and asks for a USB port. The discussion goes on from there about serial vs. USB and how to physically connect to a PC, and even some discussion about why a processor can/cannot be put in a flashlight. No one has given a realistic example of why a connection to a PC would be required or even useful.

I already said that the AKOray UI could be better. But it is very different to ask for a better mousetrap than to ask when someone will make a device which can trap a mouse.

 

[longboat]

In what way are those lights not "true end-user-programmable," which is what this thread asked for? Go back and read the original post - the OP asks for programmability and asks for a USB port. The discussion goes on from there about serial vs. USB and how to physically connect to a PC, and even some discussion about why a processor can/cannot be put in a flashlight. No one has given a realistic example of why a connection to a PC would be required or even useful.

I already said that the AKOray UI could be better. But it is very different to ask for a better mousetrap than to ask when someone will make a device which can trap a mouse.

Well, I guess it comes down to semantics, but for many of us, "true end-user-progammable" would refer to being able to program anything and everything that can be programmed. Yes, we know there are many user-programmable flashlights available, but they are only programmable within the confines of what the mfr. saw fit to include in the flashlight. As an example, how low can the AKOray lights actually go? How easy is it to obtain this low? For some people, 0.5 lumens is TOO bright!

The OP did ask to be able to connect it to his computer, presumably so that he could EASILY program it to ANY level that he desired. That is what is missing from the market, flashlights that are "computer-programmable", not "end-user-programmable", which I (and obviously many others) believe was the intent of the OP.