Everything builds (at least all the default included configs) but I can’t test all the different builds.
Glad to see you’re back Flintrock. I’ve successfully built a couple 26mm TA LDO 3s OTSM and several 1s 17mm OTSM drivers. They all used the 25V and 45V. I have some 85v 10su (have not tried them yet) that came from arrow and mouser.
Oh yeah, I’ve been meaning to ask about the 47uf tantalum capacitors. The description for the p/n you gave says 47uf , 10 volts, 20%. If it’s rated for only 10volts what will be the long term effect of running it at 3+ cell voltage? Should we find one that’s rated higher for 3+ cell drivers?
The patch is simple enough, but I can’t build the whole suite of hex files unless I rewrite the Makefile to make it unix-compatible. That will have to be a task for when I’m a bit more awake.
Well, if you built it right, the OTSM cap should be under the regulated LDO output voltage. Yes, actually placing 12V on those caps would be risky at best, but that shouldn't be happening, even in 3S.
Hmm.. I've written more Makefiles in linux than windows, and didn't particularly notice the syntax difference, but usually I start with something and make changes, so easily could have missed it. It might be that all that is needed is to define the paths correctly though (like the batch file does), and/or a couple of command aliases. I'm not sure. I like linux, but for this atmel stuff, I don't know how anyone can do as much developing as you do without the gdb interface/simulator in atmel studio. It's just too great for understanding the machine state and finding bugs, and seems completely indispensable for embedded code like this where the only other testing option is to flash it and test things one blink and re-flash at a time. Is there a simulator for linux?
However, while I didn't provide a linux-tested Makefile, I did provide one that works without atmel studio from the command-line, which might at least make a linux person a little more comfortable. Still if you're not using windows then you're not.
Oh, it looked like I just need to remove the hardcoded paths and .exe extensions, and rewrite the shell portions for Bourne shell instead of DOS. It shouldn’t be hard, but I haven’t slept much lately because I’m trying to be diurnal and that doesn’t come naturally for me.
OTOH, programming without a debugger? That’s pretty natural for me. I haven’t even looked to see if there’s a simulator, because I’ve never really needed one. I can generally figure out what’s happening by simulating in my head.
The main parts I need hardware for are to blink out measurements from the sensors, which the emulator can’t do anyway.
Yeah, ok, there might be some slashes that need to be rotated 90 degrees. Sure even simple things require making time to do it. It would be nice if there's a way to generalize it to work. Dos might even accept the linux slashes these days and I'm not sure the command syntaxes are different other than the .exe's. There may be some other details though.
It may be fine. I didn't base that selection just on the label specs though. I looked for something with good DC bias curves and good temperature derating curves. Neither are shown for that. I didn't take any chances on the prototype because I wanted to make it work, not leave myself wondering why it didn't. Of the two I'd be more worried about DC bias. Even if it's worse it will still work, it may just struggle more for example with very low batteries and/or higher timing resolution settings. Or, it may work just as well. 10V is pretty high, most DC bias curves don't fall too much before 30% of rated voltage, so it's likely to be ok. Half price is certainly nice.
Trying to catch up on a few questions:
I'm not going to say it's impossible to get a zener working, but... I think usually you use a balast resistor to set a bias current on the zener right? If you skipped that and if the zener had low enough reverse leakage, maybe it could work, maybe (or I'm wrong and it's not even maybe). Anyway, I'm not taking credit for that mod. At your own risk.
Someone asked about blf emu issues... I can't say. I don't have any attiny13's and actually I never tested it on one. I think I did test an attiny25 version of it and had it working, possibly with a modified board layout to match my test board. Not sure what's going on there. hmm...
The 17mm and 22mm 2S just differed in the used LDO,
all other parts were exactly the same,
same firmware used
Well, the precompiled one was compiled by me on windows, but it was never about windows, it was about the version of the compiler used in atmel studio 5.0. I'm pretty sure (not 100%) with exactly the same compiler version and same arguments windows and linux will give bit for bit identical binaries. The precompiled hex's were compiled with atmel studio 7.0 not 5.0. I forgot the compiler version number. On 7.0 the few times I checked, I got within a couple of bits of what I was getting on linux, with similar compiler versions.
Well that can well be the difference. The LDO needs a very low reverse leakage current. This is not being picky. The diode I first used was draining a bunch of the cap's capacity, and it wasn't a bad diode. I called out a different diode from the usual TA one for a reason. And I don't know, maybe some of the standard TA ones also work, but maybe they all don't. I think I have a note in the manual or maybe somewhere around post 69 about how low the reverse leakage current should be, probably ~ 1uA preferably when warm if I remember right, and many are much much much higher. You really have to look at the graphs for the temperature dependence too as this increases quickly with temperature on some parts.
A problem with this OTSM stuff is that the chinese budget builds are likely to run into problems if they aren't paying attention to specs.
I am building the drivers with the TA parts list, I ordered only 50 LDOs of one kind
So if I would add a diode you have listed for the 1S driver after the LDO this would fix the problem?
R6 and 7 are just 0 Ohm resistors
I know, right? It’s pretty bad. Those crazy emus are always going on about how they don’t have a problem, they can stop any time. I think we may need to stage an intervention.
Yes, the picture brings it all back, this was indeed the plan for existing boards. Yes, I think it should work. Untested of courses, but I see no reason why not.
In fact, search "R7" on the OP and you'll find that's exactly how it's written in the manual. There are other things written there about this build that you might find useful too.
Now I'll have nightmares of being chased by torch-wielding emu's.
But seriously. What is a “blf emu issue”?
I haven't looked, but this bug sounds very feasible to me. I re-organized the defines several times, and the OTSM timing variables even more times. It was actually tested with an OTC driver in a recent prior version, but probably became broken with some "clean-up". I'll try to reflect this issue in the OP soon. Good fix.
Ok, so I see now he was trying attiny25, which I think I did test at some software version, so I'm not sure.
blfa6_emu , comment somewhere around page 4. BLFA6 emu was an attempt to make a stripped-down configuration that mimics BLFA6 and allows a potentially a couple of new features. I never quite got it to fit without getting rid of something though. It still could have its uses for people who are just used to the simple interface but want some minimal extra features in an attiny25. Like you can get a very similar turbo timeout/bump-up on the attiny25 version but with actual thermal "timeout". And it can use the redundancy trick for "fastclicks" or whatever it's called to avoid the RAM corruption issue. It's a stripped down starting point for customizing a relatively simple driver.
The report of it not working is with a MTN-17DDm, not a TA board. I have no idea if it's a software problem or hardware. Randomly cycling through modes without even clicking is very strange.
I can now confirm that tocirahl’s patch looks exactly right. This was a bug I thought I’d fixed, or meant to fix and forgot :person_facepalming:
At some point somehow I thought I’d surprised myself in figuring out that doing the define that way could actually work (would be nice). Then when I came back to reality I apparently forgot to undo that one (there were others). It’s definitely a bug, one introduced after I tested OTC, and the solution is the correct one. There may actually be some way to get the defines to re-evaluate retroactively, and actually I think I previously had a problem where that was happening unintentionally, but that involved more complex macro expansion and I really never fully understood it. It would be nice to put conditionals like this alongside the code, but never mind.