Sure, it looks like DEL is ok with the latest schematic which is the most important thing with Diptrace. Once you have that, the rest is just a matter of making everything fit on the board size you want.
Send me a PM with your email and I will toss the early source files over to you. Once they get approval from those in here I will make a thread and post it all up in there for everyone.
Here is the latest schematic I am working with for reference, I also removed the embedding from the prior posts to minimize confusion.
I wanted to make sure the circuit was acceptable and I would not have to make any major changes before I started real world tests, no reason to test something you still have to make major changes too lol.
I printed it out a little bit ago and populated it with what I had on hand which was only 805 components, I had read that you can put them on the 603 pads and indeed, it looks like if you were careful they would indeed fit.
In fact it looks exactly like the 3D model that diptrace outputs, good to see that it is accurate. I measured clearances, everything looks good. I can get a programmer on it with everything installed even in 805 sizes.
So in a pinch people could build these with 805 if they really wanted.
With the 603 there should be no problems at all with fitment. Looks like you could put a 603 on the bleeder resistor if you snipped the middle pin on the 7135 as well.
I have to say, I am REALLY liking diptrace, so far it has been spot on.
Only issues I have run into past learning hiccups are some things with the copper pours. They are not really designed to do what we are doing but with a few simple work around they are manageable.
If you have anymore suggestions please feel free to let me know, you know far more then me about this kind of thing, I was an assembler, not a designer.
Difficult to get C2 any better with a 2-layer board. I am trying a 17 mm layout in Eagle, and gave up on fitting both Cs, going with only C2 = 10 uF.
Your general layout looks pretty good. Re. clearances I just get nervous because of the available fault-current with Li-ion cells. But production process are probably much better today than what I am used to.
Great, I will knock out a 20mm and 22mm version and then post them up in case anyone wants them. Any other sizes people can thing of that would be nice to have?
Finished adding, and most of the testing for new features in Narsil:
Blinks out the firmware vers #, currently v1.1 - works just like the voltage level blinking: 3X click to voltage level blinking, then dbl-click to blink out the firmware vers #
added access to the full set of strobe and beacon modes from ramping: when at max level, dbl-click goes to first strobe mode. If OFF, dbl-click to max, then dbl-click to strobes
I was able to make up a drawing in diptrace. Thanks for the recommendation!
I took the circuit from a tp4056 charging module and layed it out on a 16mm pcb. I’m not sure what of implications regarding our current firm wares especially bistro and narsil. I started a thread if you would like to comment or give some input. I still don’t know how to tune the settings of diptrace, but you can get an idea of what I am thinking.
I just had this idea for a current-regulated driver that has probably been considered before, but I couldn’t find any discussion of it.
It would be a single FET driver using PWM that would sense the average current and adjust the PWM duty cycle to keep the average current constant as battery voltage dropped.
For some applications this would be very nice I think. For example a single XPL medium mode with fixed PWM duty cycle might do 2.5A with a fresh battery but will drop to 1.5A as the cell is depleted. The proposed driver would increase the duty cycle as the voltage drops to keep the 2.5A average current constant (as long as the direct drive current is >= 2.5A). It wouldn’t keep the brightness completely constant because of the reduced LED efficiency at higher current, but it would be pretty good regulation that would be versatile and work with high currents while not producing much heat on the driver.
I guess the simplest way to detect the current would be sense resistors, but I’m not very familiar with the specifics. Any thoughts?
That it would be easier to stack a few additional ACM7135 there to get a constant output. Also I think the nice thing about FET drivers as well as the ACM7135 is that they are very simple. If you start adding a sense resistor then you have to implement a feature into the firmware. Also the voltage on the sense resistor would be tiny if you want the circuit to be efficient so you’d need an op-amp (plus a few resistors) in order to get a proper voltage output which you could measure with a MCU. So the circuit would get significantly more complex and the firmware would take up more space as well.
I think it has a supply voltage range of just 4.5V to 5.5V. But I also have to say there are people here who understand more about all of that stuff than I do. I am sure that there is somewhere a current sensing IC which would work but I also don’t know if it would be worth it. Additionally I think if you are already going through the trouble of implementing a current sensing feature then you might as well construct a proper buck/ boost driver, for example based on the TPS63020.
If you're going to flash it for a specific LED family, a simple voltage -> PWM level table would get you 95% of the benefit with no hardware complexity.
On a different topic, does this:
avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0000
0x00 != 0x0e
avrdude: verification error; content mismatch
mean I have fried the MCU? The write cycle proceeds as usual but it just won't stick. It's a tiny25 which has seen a bunch of voltage spikes while running... :( (the ones from turning off the FET at high amps).
It’s possible that the clip isn’t seated properly. It may be that it isn’t making good enough contact to sustain the default baud rate. I’ve had success in some cases by reducing the baud rate. Try something like “-b 9600” if you are running avrdude from the command line.
In the bistro firmware, what units are the Temperature settings in? I would prefer figure out what number I like and have it built into the firmware vs having to calibrate it for every light.
If I remember right it’s about 4 degrees C per digit. You will have to calibrate anyway, since the temperature measurement of the mcu is not exact at all.
Yeah, I know I should calibrate but I get lazy when building a bunch of lights and wanted some number that was close in case I didn’t.
Plus honestly a 10c+ swing in temps doesn’t bother me as long as it keeps it from getting dangerously hot.
I lowered the step down time to ~8 seconds and think around 90 as the starting temp threshold seems to work well for a starting point. Although I think I might step the stepdown time down to 5 seconds as it takes awhile to step down from turbo.
Most of the firmwares (including Bistro I think) are using the ADC in 8-bit mode to save on memory space (left-shifting the ADC result and reading only the high byte). When moving up to the 25 or 85 there is no real reason to do this. We can comfortably fit a few 16-bit variables in memory and use the ADC in full 10-bit mode.
In 10-bit mode the ADC reads approximately 1 C per ADC count, with 300 = 25 C (it is kind of a Kelvin scale). With the ADC in 8-bit mode the result is approximately 4 C per count, with 75 = 25 C. Very difficult to achieve any kind of control, PID or otherwise, with the 8-bit mode.
With the bistro setup as I have it now (already had to turn off the better bike strobe, not that I really care) I am at 99.3% or 2034 bytes. So I only have 14 bytes left to play with.
Do you think there is enough room to switch to 16-bit mode? If so, which numbers would I change? That kinda taxes my skill limit with coding. I speak C well enough to stand around people having a conversation and nod my head at the right times but thats about it.
