LED strobe

[jspeybro]

found some interesting reading material on pulsing cree LEDs: http://www.cree.com/products/pdf/XLamp-Pulsed-Current.pdf
for this application, duty cycle will be well below 25%. The document suggest not to go over 300% of the rated current, so one could use 2.8A drivers for 1A rated LEDs. Running 2 of these drivers at the same time off 1 battery will not be possible due to overcurrent protection circuitry I guess. If 1 LED at 2.8A or 2 LEDs at 1.4A produces the same amount of light, I guess not since efficiency goes down when increasing the current. I suppose 2 LEDs at 1.4A could be a good compromise.

 

[jspeybro]

I'm using this programmer: http://www.voti.nl/wisp628/n_index.html with xwispw.exe to program the chips. It's connected to a ZIF socket that uses a USB connection for power. The programmer takes its power from the target.
It's my brother's and it works fine on his laptop (newer). When I use it on my laptop, it fails at the moment it starts writing the code to the chip. I'll see if I can post the output after work.
Any idea if these programmers are any good? http://www.piccircuit.com/7-pic-programmer
they seem cheap, small and work on USB which may overcome the issue I'm having.
Edit: I just noticed that the website of the programmer doesn't mention the 12F629 as being supported. there are however different versions of this software so apparently these don't have problems with the chip. I'll provide more info on the software I'm using after work.

never mind. I was doing something wrong with the software. It works now.
Now lets do some programming :naughty:

Johan

 

[DIWdiver]

never mind. I was doing something wrong with the software. It works now.
Now lets do some programming :naughty:

Johan

Good! I wasn't going to be much help anyway.

I don't know much about the programmers on piccircuit.com, but they certainly are cheap! I might have to try one.

 

[jspeybro]

Hi guys,

the programming is comming along faster that I expected. I currently have 4 pins flashing at 1Hz 1 after the other. a flash currently takes 10ms which seems a reasonable value to start with. this is really a flash, not sure if it would be better to increase the time a little.
also, 1Hz seems a bit fast to me. I think it would be quite anoying. 0.5Hz seems more reasonable to me, not sure what you think about this Packhorse.

I'll see if I can clean up the wiring and make a little movie. That will probably give a better idea about what I'm talking about.

Since I'm currently using the PIC12F629, I don't think I'll be able to implement the battery monitoring on this chip (the circuit I had in mind needs an ADC which is on the 12F675; I ordered 12F675 chips, but I'm affraid they got lost in the mail :scowl

I guess the next thing I could do is try to implement modes by using the brownout detection and a capacitor between supply and ground.
If anyone is interested in the assembler code, I can post it here, but I think I'll first need to clean up the code and it will probably be more interesting once modes are implemented.

Johan

 

[jspeybro]

Excellent Johan.

My thoughts were for the PIC to prive a AMC7135 directly so no MOSFET needed. The AMC will take care of current control. It requires a hi input from the PIC.

To be honest, I didn't read the AMC7135 datasheet in detail until now. I missed the fact that the chip only draws 200µA at Vdd and the high current is just supplied from the battery. I guess that indeed means that we don't need mosfets for switching the LEDs. Great, I'll do a quick check to verify.
That would mean that with the current assembler code, I just have the microctontroller with no extra components. Being able to detect battery power would require at least a diode and a resistor. being able to use modes will add a capacitor. that's still only 4 components.

Johan

edit: seems to work without the mosfet by directly controlling the Vdd of the AMC chips. just connect the ground of the driver to battery -, the led - to the output of the AMC's and led + to battery +. The output of the mcu can go to the center connection of the driver (where you would normally connect battery +. Don't do it with the mcu setup or you'll connect the bettery + to the output of the mcu) or behind the diode. I guess keeping the diode would be better for reverse voltage protection.

 

[jspeybro]

ok, so far I have the following implemented in the pic12F629:
* detect brown-out situations to use that for switching modes (same principle als DX modes implementation) - the capacitor needed will probably be 10µF or something (gives you a bit more than a second to switch on-off-on)
* flash 4 LED(-pairs) at a set frequency and duty cycle, 1 LED(-pair) at a time.
* for testing purposes, a small LED will light up when it detects a mode switch. no need to connect a LED in final setup
* as stated in the previous post, the output of the chip can be used to switch AMC7135-based drivers directly since the AMC chips have the necessary switching capabilities.

I'm almost done with the code for detecting which mode is selected so now, the question is which modes would need to be implemented.

I was currently thinking of having 2 or 3 different strobe frequencies and 1 additional mode that ligths up 1 pair continuesly (or maybe modulated at high frequency to dim it (PWM) since full power will run the LED(s) above specifications risking damage to the LEDs which would not be pleasant in an emergency situation).
So far, I haven't looked into implementing an SOS mode, not sure if that is necessary.
Let me know what you need Packhorse.

Once I finish the code for the modes I'll post some code for the other techies to review and then I'll have closer look at comparators. Maybe I don't need the ADC of the 12F675 to monitor battery voltage although I will probably need a voltage reference and perhaps some extra resistors. 12f675 would likely be the better choice for battery monitoring though (less components)

Any progress on the mechanical parts?

Johan
Edit: uploaded a little video

I started recording just after the battery was connected. There is a normally closed button that allows me to simulate on-off-on sequences. The blue led on the left lights up to indicate if a mode switch was detected. There are 2 frequencys implemented in this video (not properly implemented yet, but seems to work). The first time I push the button, it switches modes; the second time, it restarts from the first mode. The PIC is burried somewhere between the cables at the left side of the breadboard.
I use these small leds to prevent me from going insane with the bright flashes from overpowered high power leds ;-)

 

[Packhorse]

Looking good!

I dont see any point in a SOS mode.
Can I assume if you wanted to drive 2 LED's you could pair up the 4 outputs? Or I guess you could just use 2 instead of all 4?

I have not started on the body or heat sink yet as I really need to have the unit for dimensions. But then it shouldnt take long to knock something up.
Do you have a rough idea of finished size?

 

[jspeybro]

Can I assume if you wanted to drive 2 LED's you could pair up the 4 outputs? Or I guess you could just use 2 instead of all 4?

Not really sure what you mean. I'm now using 4 pins because I understood that you wanted to use 8 XR-E's and light up 2 at a time. If you only want 2 LED(-pairs) instead of 4, I can easily change that. I can imagine that 8 XR-E's and 8 drivers take up quite a bit of space. Do you want to have the possibility to choose between 2 and 4 (then connecting pins would be easiest).
I'll do test this evening to see if it is possible to connect to of the outputs to do the same without reprogramming things. Since there will only be current on 1 pin at a time, this might work, but I don't now what will happen if an output gets incomming current.

as long as I don't do batterymonitoring, I only need the PIC and a capacitor so that would not be bigger than 1cm². If I would place it on a board, it will get slightly bigger but not sure if that is necessary for only 2 components.

Johan

 

[DIWdiver]

Johan,

You should not connect two PIC outputs together unless you are VERY careful to they are driven to the same level ALWAYS. If you do this even for a short time, you will destroy something in the PIC.

You can, however, connect an input pin to an output. Thus you could set all 4 pins as input, then turn them to outputs one at a time. If you do this, you could tie any of the 4 pins together to get different patterns.

The only problem with this is that there is nothing to drive the pins low. The '7135 boards may pull the pins down to near ground, maybe not. If an input is left floating and ends up kind of in the middle of the voltage range, the PIC will draw extra power. You wouldn't notice this compared to the power of the LEDs when running, and it won't hurt anything, but it's not considered good design practice. When the light is switched off, you drive all pins as output low, to ensure the PIC draws low power.

Another thing that can help protect the PIC is to put a low value resistor in series with each output pin. 100 ohms should protect the PIC, but I don't know if that would be too much for the '7135 boards to work properly.

Don

 

[MikeAusC]

I'm pretty sure PIC outputs have short-circuit protection.

 

[jspeybro]

I guess that's a bit too much work, just to be able to connect less leds but keep the frequency. It's much easier to just reprogram the PIC. If both situations need to be covered, why not have 2 pics with different code? it will be for different lights anyway.
I think this issue is more a misunderstanding than a problem to solve.
Btw, the AMC's only draw 200µA max from the output of the pic so I doubt it would pull the pin down.

anyway, I changed the code for the modes and can now easily add any number of modes with any desired frequency, duty cycle and number of LEDs so we'll just need to agree on something I guess.

I'll see if I can clean up the code and comments a bit in the coming days and I'll post the code if someone is interested. I suppose this code can also be used to reprogram PIC12F629-based DX/KD drivers. It just needs some other frequency settings and limit to 1 LED instead of 4 (just need to change 2 registers for the LEDs and a few numbers for the modes)

Johan

 

[DIWdiver]

I'm pretty sure PIC outputs have short-circuit protection.

No, they absolutely do not. At least if you're talking about the 10F, 12F, 12C, 16C, 16F, 18F, 24F, or '33 families. I'm not that familiar with the and '30 and '32 families or the defunct 14F family.

 

[DIWdiver]

I guess that's a bit too much work, just to be able to connect less leds but keep the frequency. It's much easier to just reprogram the PIC. If both situations need to be covered, why not have 2 pics with different code? it will be for different lights anyway.
I think this issue is more a misunderstanding than a problem to solve.
Btw, the AMC's only draw 200µA max from the output of the pic so I doubt it would pull the pin down.

Johan

Agreed, maybe it's a solution looking for a problem, but it's almost trivially easy. You just write the TRIS bits to 1, the GPIO bits to 1, then any time you want to change an output, you just work with the appropriate TRIS bit instead of the GPIO bit.

You might want to check the '7135 boards to see if there's a bypass cap on the line you'll be driving from the PIC. If so, the 100 ohm resistor is a good idea regardless of whether you are thinking about tying pins together or how you are manipulating the IO. Driving a 0.01uF or larger cap directly from a port pin is pretty stressful on the pin drivers, and under some conditions can trip the brownout detector. If there's a big cap (bigger than 0.1uF), you may want to (on second thought, make that 'you really should') use a 220 ohm resistor, which would actually limit the current to within the absolute maximum rating. At 200uA, that would only drop 44 mV, which probably wouldn't make any difference to the '7135s.

 

[jspeybro]

The datasheet of the AMC7135 provides a typical circuit for the chip. That circuit has an external bypass cap (Cbp) so I'm guessing it doesn't have one itself. It's not mentioned explicitely in the datasheet as far as I can see. This would mean that we can directly connect the pin to the chips I suppose.

 

[jspeybro]

Small update (small because I went diving instead of coding assembler ;-) )

I cleaned up the code a bit.
I implemented the modes in a better way now that is easier to manage/change
I read/write the selected mode from/to EEPROM memory so it remembers the last mode that was used at power-up.
Implemented 3 modes for now. 2 flashing modes at different frequencies/duty cycles and 1 mode that is lighting up some LEDs continuesly in case you want to use it for backup illumination.

to be done is choose the frequencies of the modes, the number of LEDs to control and to implement battery monitoring.

By now, I got confirmation that the 12F675's that were on the way will never reach me so I'll have a look to see if I can do some basic low voltage detection on the 12F629.
I was thinking of using a diode and a resistor by connecting the common node to the CIN+ of the comparator. The resistor is between an output and the input of the comparator and the diode between the comparator and the ground (battery -). The diode will provide a constant voltage drop. This will be compared to the internal VREF using one of the scaling factors. I might need to use a LED to increase the voltage drop (more experiments ) ). Once the voltage of the battery (and with that, VREF) drops below a certain point, the pic will keep this in memory and give some warning and/or switch to a low-battery mode to extend battery life.
I never tried this before so let's hope this works fine. not sure which resistor to use, probably high enough to limit the current through the diode.

any suggestions around which point it should give a low battery warning/switch?
If a 18650 from dealextreme operates between 4.15 and 2.75V, there would be 10% left in the battery when there is 2.89V left. [(4.15V-2.75V)*0.1+2.75V]. update the 0.1=10% to get the voltage for different percentages.

any suggestions on what should happen in the case the battery gets low?

Johan

testing if this forum supports code fragments... => apparently it does :-)

 

[wquiles]

any suggestions around which point it should give a low battery warning/switch?
If a 18650 from dealextreme operates between 4.15 and 2.75V, there would be 10% left in the battery when there is 2.89V left. [(4.15V-2.75V)*0.1+2.75V]. update the 0.1=10% to get the voltage for different percentages.

any suggestions on what should happen in the case the battery gets low?

Johan

It depends on whether you are testing the cells during the ON cycle of the PWM, or the OFF cycle, or if you are using an average value. For the PhD-M6 Eric Marshall discussed this same question, and we tested both ways (loaded and unloaded), and it was not a huge difference since in out application there was not a lot of time for the cells to "recover". Your application might be different, so you might want to consider testing both ways.

That being said, the 2.89volts you are considering is (in my opinion) way past the depletion point. Once a LiIon cell's voltage goes below 3.6-3.7 volts, you don't have much charge in them, and that was why we picked 3.7-"ish" in the PhD-M6 as the point where the cell had about 5-10% left. Granted, we were running a voltage regulation product, but, if you look at post #515, you will see that depleted cells from driving an MN20 bulb got to the 3.4/3.5 volts where they were already depleted, so the 3.7v I mentioned before would be better as you really don't want to fully deplete LiIon cells too many times.

In my humble opinion, the best thing to do is to do what we did:
- charge your cell with a smart charger, like the Triton I used, so that you know how many mAH you are putting on the cell during the charge.
- put your cell under test, and stop the discharge at your theoretical target (2.8v, or 3.7v, whatever)
- charge back your cell, and note how much mAH you put back
- repeat the charge/discharge (under load) at different trip points

=> the values from the Triton, compared to the rated mAH from the battery will give you an approximate idea of how much charge is left in the cell at each trip point (and note that a cell marked 2800mAH is really NOT 2800mAH - it is normally less than that in real life, even new cells). Doing this for "your" setup would be the most accurate way of setting the trip point.

My 2 cents.

Will

 

[DIWdiver]

Small update (small because I went diving instead of coding assembler ;-) )

I cleaned up the code a bit.
I implemented the modes in a better way now that is easier to manage/change
I read/write the selected mode from/to EEPROM memory so it remembers the last mode that was used at power-up.
Implemented 3 modes for now. 2 flashing modes at different frequencies/duty cycles and 1 mode that is lighting up some LEDs continuesly in case you want to use it for backup illumination.

to be done is choose the frequencies of the modes, the number of LEDs to control and to implement battery monitoring.

By now, I got confirmation that the 12F675's that were on the way will never reach me so I'll have a look to see if I can do some basic low voltage detection on the 12F629.
I was thinking of using a diode and a resistor by connecting the common node to the CIN+ of the comparator. The resistor is between an output and the input of the comparator and the diode between the comparator and the ground (battery -). The diode will provide a constant voltage drop. This will be compared to the internal VREF using one of the scaling factors. I might need to use a LED to increase the voltage drop (more experiments ) ). Once the voltage of the battery (and with that, VREF) drops below a certain point, the pic will keep this in memory and give some warning and/or switch to a low-battery mode to extend battery life.
I never tried this before so let's hope this works fine. not sure which resistor to use, probably high enough to limit the current through the diode.

any suggestions around which point it should give a low battery warning/switch?
If a 18650 from dealextreme operates between 4.15 and 2.75V, there would be 10% left in the battery when there is 2.89V left. [(4.15V-2.75V)*0.1+2.75V]. update the 0.1=10% to get the voltage for different percentages.

any suggestions on what should happen in the case the battery gets low?

Johan

testing if this forum supports code fragments... => apparently it does :-)

Hi Johan,

Using an external voltage reference diode with bias resistor controlled by a port pin is a great way to get stable reference voltage and really low average power.

However, I would rather not use the forward voltage of an ordinary diode as a voltage reference. The voltage is highly dependent on temperature, current, and the device selected. With care, you might achieve +/- 5% accuracy, or without care you might get +/- 10%. You could certainly argue that for battery cutoff this is accurate enough, but unless you are building so many that you are counting cents per part, I would aim higher. Much better than a simple diode would be to use a reference diode like the venerable LM431, or it's many copies (with prefixes of TL, ZTL, TLV, AP, et al. instead of LM). There are more accurate references available, but for 0.5-2% accuracy, the '431 is fine, and the cheapest around. The most common voltage is 2.5V, but 1.5, 3.3, and other voltages are available. Very similar are the '432 and '285/385 parts.

Don

 

[jspeybro]

thanks for the tips. since I don't have a voltage reference at the moment, I just went ahead with the simple diode, just to check that the code is correct. This seems to work as I had hoped. When 1 of the LEDs is enabled, current starts flowing through the diode (resistor between output pin for LED and CIN+ of the comparator and the diode between comparator and battery-). I set the voltage reference scaling factor to 0.167. Each time that specific LED is lighting up, the battery is checked. I added a variable voltage divider between the battery and the pic to simulate a low battery situation and the system seems to trip when the voltage goes below 3.6V, which is good concerning the info from wquilles. Once it trips, I currently just change the frequency, but there are other possibilities.

DIWdiver, you have a very good point regarding the sensitivity of the diode to temperature, I'll need to look into that. A voltage reference is probably the best solution although I never used that. but it seems simple enough.

One thing that concerns me a bit (wquilles already mentioned this as well) is that I'm currently checking the battery under load (at the time when 1 or 2 LEDs are on so this would be a quite heavy load for the battery). I suppose the voltage would drop at that point, falsely tripping the low battery system. If I don't need to flash 4 different LEDs/pairs, I could use a separate output specifically for battery monitoring and check the battery while no LEDs are on and preferably just before a flash so that the battery has the most time to recover. Another solution could be to connect the resistor directly to the supply voltage instead of an output pin. The disadvantage would be that it would draw current continuously.
More experiments on the way to find out what the best way is...

anyway, the component list so far is just the PIC, a resistor, a diode and a capacitor which could be soldered in a very compact circuit, only slightly bigger than the chip.

Johan

 

[DIWdiver]

...The disadvantage would be that it would draw current continuously...

Johan

The LM431 can operate on currents below 0.1 mA which would be insignificant compared to the other loads. If you use a 10K resistor and a 2.5V reference, you'd have about 0.1mA at end of battery life, about 0.15mA at the beginning. As long as the reference pullup resistor is tied to the power switch so you turn it off when the unit is stored, the drain contributed by the reference can be neglected.

 

[jspeybro]

AMC drivers are mounted behind LEDs in a milled out space. I have doubled up the chips on the board and added a thermal switch.

could you provide some info on the thermal switch and how you use it? Not sure if it is necessary for this project, but seems interesting for one of my other projects.

Johan