[UPDATE:v1.7.1,Q8&1chanOTSM]bistro-HD, bistro your way. OTSM, eswitch(devel), Vcc reads, safe_presses, turbo timeout...

245 posts / 0 new
Last post
Lexel
Lexel's picture
Offline
Last seen: 15 hours 5 min ago
Joined: 11/01/2016 - 08:00
Posts: 5248
Location: Germany

The 17mm and 22mm 2S just differed in the used LDO,
all other parts were exactly the same,
same firmware used

Flintrock
Offline
Last seen: 1 year 8 months ago
Joined: 09/10/2016 - 20:29
Posts: 1544

DavidEF wrote:
KFulton wrote:
When I compile this in Atmel Studio, I get a different (slightly larger) filesize from the pre-compiled .hex. Compiling in WinAVR gives yet another (even larger) filesize. Any idea what I might be doing wrong? Or does it even make a difference?
Short answer - Windows sucks. Texas_Ace was the first one I saw mention this, but someone else _may_ have noticed it earlier. Compiling in Linux results in smaller file sizes.

 

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.

Flintrock
Offline
Last seen: 1 year 8 months ago
Joined: 09/10/2016 - 20:29
Posts: 1544

Lexel wrote:
The 17mm and 22mm 2S just differed in the used LDO, all other parts were exactly the same, same firmware used

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.

Lexel
Lexel's picture
Offline
Last seen: 15 hours 5 min ago
Joined: 11/01/2016 - 08:00
Posts: 5248
Location: Germany
Flintrock wrote:

Lexel wrote:
The 17mm and 22mm 2S just differed in the used LDO, all other parts were exactly the same, same firmware used

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

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 2 hours 1 min ago
Joined: 01/12/2013 - 14:40
Posts: 9804
Location: (469219) 2016 HO3
Flintrock wrote:
Someone asked about blf emu issues…

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.

Flintrock
Offline
Last seen: 1 year 8 months ago
Joined: 09/10/2016 - 20:29
Posts: 1544

Lexel wrote:

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 !{width:50%}http://www.metronixlaser.de/bilder/flashlight/30mm_2S_OTSM.png!

 

 

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.

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 2 hours 1 min ago
Joined: 01/12/2013 - 14:40
Posts: 9804
Location: (469219) 2016 HO3

But seriously. What is a “blf emu issue”?

Flintrock
Offline
Last seen: 1 year 8 months ago
Joined: 09/10/2016 - 20:29
Posts: 1544

tocirahl wrote:
Not sure if this is the right place to post this, but I think I've found a bug in the bistro-HD code. In the classic configuration (OTC, no OTSM, no E-SWITCH) , it seems that the wake_count_med and wake_count_short variables are being set to their OTSM values (as defined by wake_time_short and wake_time_med) instead of their proper OTC values (as defined by CAP_MED and CAP_SHORT). It seems the proper undefs / redefs appear in the code in the wrong place and aren't getting picked up correctly and should be put at the top along with the other defines. The result of this bug is that in the OTC configuration it is nearly impossible to "medium press," since short press is set to ~6 and medium press is set to ~9. Short press works ok but is _very_ short as a result. I'd be more than happy to submit a patch if you guys accept those?

 

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.

Flintrock
Offline
Last seen: 1 year 8 months ago
Joined: 09/10/2016 - 20:29
Posts: 1544

ToyKeeper wrote:
But seriously. What is a "blf emu issue"?

 

KFulton wrote:
After giving up on trying to fit a 17mm TAv1 into a Convoy S2 (the "shelf" on the pill is wider, so R4 usually gets crushed), I built a BLFA6_EMU hexfile with custom modegroups and flashed it onto a MTN-17DDm with ATTiny25. It flashes OK, but when I power it on, it just randomly cycles through all of the modes. I've checked through fr-tk-attiny.h and the pins look correct. I'm not sure where to look next.

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.  

 

 

RotorHead64
RotorHead64's picture
Offline
Last seen: 1 month 6 days ago
Joined: 10/31/2015 - 02:49
Posts: 428
Location: United States
Facepalm Thumbs Up
Flintrock
Offline
Last seen: 1 year 8 months ago
Joined: 09/10/2016 - 20:29
Posts: 1544

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 Facepalm

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.

Flintrock
Offline
Last seen: 1 year 8 months ago
Joined: 09/10/2016 - 20:29
Posts: 1544

Version 1.3.2  Bugfix for OTC breakage in last release thanks to tocirahl for catching it.

http://s000.tinyupload.com/?file_id=86118170622813962762

-1.3.2 Bug fix for broken OTC timing, also updated the packit build target in the Makefile 

 

Updated in the OP.  Also note, as stated in the OP, the tested version (as in many or most of the builds were tested, not just OTSM) is 1.1 (1.0 is probably even more tested)  Some glitches like this in newer releases are probably to be expected as I and others probably can't test every build with every release, and going forward that will probably require community feedback.  If 1.3.2 doesn't work you, you might try 1.1, but please report back either way.  KFulton, this advice might apply to you.

 

In the comments of the OTC wake timing defines there is also now a start to to more advanced timing method, not implemented yet.  The idea is to run higher timing resolution up until the end of the short press, and slow it down after that, getting more fine grained timing control and saving cap performance too.  It gets a little messy though and maybe it's not needed.  Feedback from anyone trying higher timing resolution and shorter med click would be useful. I feel the default 1/2 s medium click is a bit too long, but 1/4 second might be too short, hence the need to double the timing resolution, to be able to make it 3/8 maybe.

 

 

Flintrock
Offline
Last seen: 1 year 8 months ago
Joined: 09/10/2016 - 20:29
Posts: 1544

Flintrock wrote:

Lexel wrote:

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 !{width:50%}http://www.metronixlaser.de/bilder/flashlight/30mm_2S_OTSM.png!

 

 

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.

 

To be a little more explicit here, the divider resistors are also documented there for series builds.  I'm surprised if you got OTSM to work at all if you followed TA resistor values, but working and working well/reliably/reproducibly aren't the same either.

Flintrock
Offline
Last seen: 1 year 8 months ago
Joined: 09/10/2016 - 20:29
Posts: 1544

Oops, I forgot to rebuild the hex’s in the posted 1.3.2 release Facepalm . The link is down now and there will be a 1.3.2-r1 link up in it’s place very shortly (if not already).

Flintrock
Offline
Last seen: 1 year 8 months ago
Joined: 09/10/2016 - 20:29
Posts: 1544

OTSM and zener

 

So it's been too long since I thought about some of these circuits.  I dug this diagram that I made back up from the firmware development thread:

 

I'm liking this asci art for discussion.  For future use, here's a full diagram of the standard TA layout (minus the LED circuit) with zener, I've changed the 5R resistance value to simply the R5 resistor label.  I've actually never seen the circuit laid out as a full loop before.

 

                         Batt+    Batt-

                          |--|  |-----|

                          |           |--------*<-----|  (tail cap LED, shorted by switch)

                          |           |---------/ ----|  (tailcap switch)     

                          |                           |

                          |                           |

                          |---------BR----------------|  (case ground plane, not equal to batt- when tailcap led is on)

                          |                           |

                          R5                          |

                          |               C1          |

                          |---------------||----------|

                          |                           |

                          |-----------R1---R2---------|

                          |              |            |

                          |             Vsense pin    |

              (Schottky)  V                           | 

                          |--------------mcu----------|

                          |-------------<(zener)------|

                   Vcc    |--------------||-----------|        

                                         C2

 

 

So, I had forgotten that TA's zener mod has a schotkey.  I'm fairly sure early zener hacks didn't necessarily all have that.  I also see that there is no balast resistance in parallel with the mcu, so that's fine.

 

So actually YES,   I think OTSM could  work with the zener mod, and that actually seems to be the context of the discussion I posted this figure in the first time.

The big question really is how fast and hard does the zener shut off as the voltage on C2 starts dropping from power shutoff.   If it shuts down fast (for example 0.3V might be ok) and hard (<3 uA), then it should work the same as an LDO would.

 

 

 

 

KFulton
Offline
Last seen: 2 months 3 weeks ago
Joined: 04/12/2017 - 12:31
Posts: 27
Location: Rochester, NY USA
Flintrock wrote:

Version 1.3.2  Bugfix for OTC breakage in last release thanks to tocirahl for catching it.


Updated in the OP.  Also note, as stated in the OP, the tested version (as in many or most of the builds were tested, not just OTSM) is 1.1 (1.0 is probably even more tested)  Some glitches like this in newer releases are probably to be expected as I and others probably can’t test every build with every release, and going forward that will probably require community feedback.  If 1.3.2 doesn’t work you, you might try 1.1, but please report back either way.  KFulton, this advice might apply to you.

I scrapped that build and ended up filing down the edges of the pill shelf so that a TAv1 would fit, but I still have the flashed/broken board. I will try the older build the next time I put together a S2+.

Flintrock
Offline
Last seen: 1 year 8 months ago
Joined: 09/10/2016 - 20:29
Posts: 1544

Just recently reviewed the BLFA6 config.  There's nothing particularly special about it other than a different board layout. It doesn't even use the new thermal bump-up.  It's basically just bistro with fewer modes and channels, and the 8 bar battery indicator.  There is a possibility that some pin state settings are causing an instability in that layout suppose, but that's a wild guess.

 

The other thing though is that it is an OTC build, so certainly that was broken in the original 1.3 release, should be fixed in the latest release, and in the 1.1 release.

 

Yeah, if you felt like getting another data point it might provide a clue.  I can't remember now is the DD17 driver you used identical to the original BLFA6 driver? Did you have to change the layout config?

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 2 hours 1 min ago
Joined: 01/12/2013 - 14:40
Posts: 9804
Location: (469219) 2016 HO3

It’s updated in the repository now.

Flintrock
Offline
Last seen: 1 year 8 months ago
Joined: 09/10/2016 - 20:29
Posts: 1544

One thing I am noticing in the BLFA6_emu is that the attiny>13 builds (the only ones that actually fit without removing a strobe or something) ,  the present version of the config does NOT use temperature step-down bump-up.  It uses standard bistro "regulation".  That's probably not how I meant to have it.  I'll most likely change that in the future (already did in my development branch).  Of all the builds that should get that feature by default, it seems this one should.  I mean this feature was actually inspired by BLFA6's timeout in the first place.  Oops.  Oh well, not a problem until someone actually has it working, not to say that it's broken, we don't know yet, it may just be broken/not-configured-for KFulton's particular hardware, just don't know.

 

@KFulton Come to think of it, this may very well be your "bug".   The bistro temperature regulation fluctuates the level up and down to try to control the temperature (I don't really like it personally, but it's all good because others do).  Were you using turbo?  Even if you weren't, maybe there's an issue with temperature readout, the default calibration, etc.  One thing you could do try if you play with it again is going in the temperature calibration mode (menu 7), and clicking out during the initial 2-second low light phase.  That should disable temperature regulation. 

 

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 2 hours 1 min ago
Joined: 01/12/2013 - 14:40
Posts: 9804
Location: (469219) 2016 HO3

Bistro’s thermal regulation is pretty bad, TBH. It was barely sufficient for a single emitter in an X6v2 host, and probably not a good idea on anything with a higher power-to-thermal-mass ratio. I’ve made much better methods since then, but I haven’t tried to make them fit on attiny25 for bistro yet. I did at least put an upgraded method into Crescendo, but it takes a sizable chunk of the ROM and the adjustments are still pretty noticeable. The Crescendo regulation pattern looks like this:

Note: It’s normal and expected for the lumen output to rise a bit as the battery gets low, because there is less voltage difference between the battery and emitters… and therefore less heat. So, it can put out more light at the same temperature. And it aims for constant temperature, not constant brightness.

Flintrock
Offline
Last seen: 1 year 8 months ago
Joined: 09/10/2016 - 20:29
Posts: 1544

For what it's worth, I quite like the step down I've implemented.   For anything but trying to get max lumens on a bicycle (changing wind conditions, undesirable to have operator intervention) I don't need anything more.  As I've said before, my new method is intended to supplement TURBO modes, not regulated sustainable light levels.  TURBO should go beyond sustainable and be available in bursts when you decide you need it.  For turbo, presumably you're holding the light and in normal operation you don't even truly need anything on a decent quality light where the electronics won't overheat without the case getting hot.  This thing provides a measure of protection in case you forget and set it down, while still providing the above, and the behavior will feel very similar to BLFA6, just auto-tuned to the thermal capacity of the light.

 

The new thing does this very very well in my opinion.  I might just go ahead and make it default in classic and tripple-down as well if  even the inventor isn't crazy about the old thing.  Of course it's still not a regulated mode.  It's a turbo protection.

 

Oh, and this is a nice plot. Well done.

 

 

 

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 2 hours 1 min ago
Joined: 01/12/2013 - 14:40
Posts: 9804
Location: (469219) 2016 HO3

Awesome, I didn’t remember that you upgraded bistro’s thermal code for bistro-HD. It looks like it does better than bistro in quite a few ways.

I’ve been meaning to merge the updates into regular bistro, or at least the parts which work on the old hardware, but I’ve been preoccupied with other projects. I was probably a ferret in a past life, because I like shiny things and my attention span is— ooh, what’s that shiny thing over there?!

If you ever get the urge to do runtime graphs, zak.wilson’s ceilingbounce app makes it pretty easy. I found it extremely useful when testing thermal regulation algorithms and a few other things.

Normally I don’t really care about thermal regulation. It’s easy enough to regulate the temperature manually. However, I’ve found that companies who sell lights don’t want to sell anything which could overheat when given to a monkey. So to make them happy I’ve spent way too much time trying to monkey-proof things lately.

Flintrock
Offline
Last seen: 1 year 8 months ago
Joined: 09/10/2016 - 20:29
Posts: 1544

BLFA6_EMU issues

 

I can now can confirm that 1.3-r2 BLFA6-emu was designed for people who embrace the unexpected, who like surprises, who are not frantically trying to control everything around them.  If you are a free spirit like this, I will bring back 1.3-r2 for you.  If you prefer to be more boring and control-freak like, and want modes to be actually predictable, you should use verstion 1.1 for BLFA6 for now.

 

I don't know what's causing this.  1.1 does work, but it has (non-problematic) quirks too.  First, on first boot it starts in the menu, not horrible, but quirky, probably not too hard to track down.  Second, I did get the same random mode change behavior with 1.1, but only when it running it still plugged into the usbasp.  So that's interesting.  One thing 1.3 did was "improve" pin  state settings, and leaving it plugged into the usbasp is likely to pull floating pins up or down.... hmm.  It's usually a bad idea to run that way, and often does strange things, but it's interesting that this time it does this particular strange thing.

 

1.3.2-r2 now has blfa6 still broken, but differently, so that may be a clue too.  I'll have to track it all down.  It's very likely either the pin state changes, thermal regulation changes, or changes to the fast presses code, as those are basically the areas with changes. It may not be isolated to only BLFA6, although I don't see any problem with tripple channel OTSM or OTC.  

Flintrock
Offline
Last seen: 1 year 8 months ago
Joined: 09/10/2016 - 20:29
Posts: 1544

 solved

 

I was initializing the default mode at startup but it has to be initialized after failing to read a saved mode.  The failed read left it at 255.  This resulted in a chain of undefined events that eventually led to an array under-read to set the level from some random changing piece of memory.  The bug existed in 1.1, but other randomness resulted in it starting in the menu which actually fixed the mode_idx. 

 

This was all fine on other builds because they used a different mechanism for first initialization, which is probably why I missed it.

 

The next release will include this fix, and probably not  much more, so as to hopefully make a it a more stable release, not a more featured one.

 

 

Flintrock
Offline
Last seen: 1 year 8 months ago
Joined: 09/10/2016 - 20:29
Posts: 1544

Voltage read-out handbook: dividers, Vcc, "internal", LDO, demystified

 

Adding some sections to the manual in next release:

 

                  Appendix A.  Voltage Readout Methods
                  
Method 1, Classic divider  (Non-OTSM, 1S or series):
 Config options:  READ_VOLTAGE_FROM_DIVIDER

Traditionally voltage is read across a voltage divider made from the R1 and R2
resistors.  The ADC readout is made relative to the internal 1.1V reference. 
In other words the ADC result is V_divider/1.1V * 255.  This method does not
work for OTSM, because the voltage pin detects power off when voltage is below
about 1.5V.  For this method, all divider voltages must be below 1.1, which
won't work for OTSM.

  When to use: For any build without OTSM
  Advantages: Works in 1S and 2S, 1 point calibration possible.
  Disadvantages:  Doesn't work with OTSM, requires a divider.

 

Method 2, inverted (aka "internal") reads  (1S OTSM):
 Config options:  READ_VOLTAGE_FROM_VCC
 
This has been become known as "internal" voltage reading.  It effectively just reads
Vcc, or the voltage on the supply pin of the mcu.  However it does this
actually reading the internal 1.1V reference, but reading it referenced to Vcc,
essentially inverting the result.  The ADC value procued is 1.1V/Vcc * 255. And
clearly Vcc= 1.1*255/ADC. It works well when Vcc represents the battery
voltage, ie in 1S.

  When to use: Can use for any 1S build, but useful for 1S OTSM
  Advantages: Should work pretty well with no calibration, and easy to adjust.
            Can be used on small boards with no voltage divider.
  Disadvantages: 1S only, Calibration theoretically more difficult to get exact.

 

Method 3 Vcc-referenced divider reads (LDO OTSM method)
 Config options:  READ_VOLTAGE_FROM_VCC
                  REFERENCE_DIVIDER_READS_TO_VCC
                 
Like method 1, but references the divider read to Vcc.  ADC result is
V_divider/Vcc * 255.

When to use it:  This works for any LDO build, ie builds where Vcc is regulated
and can be used as a reference.  It is only needed though for OTSM LDO builds,
but is likely to be better than Method 1 for any LDO build, due to the more
stable voltage reference.

  Advantages:Most stable voltage reference can mean calibration-free.
  Disadvantages:  Requires regulated mcu input voltage (won't work in 1S)

  Note, this may work on zener builds in theory, but depends on the stability
  of the zener (for OTSM it also requires a quality schottkey protection diodes and
  depends on the leakage of the zener).


Summary:
For non-OTSM builds with a divider the classic divider method is fine. 
For 1S-OTSM or 1S with no divider or 1S for calibration free use, use inverted
reads (Meth 2).
For LDO-OTSM builds, use Vcc-referenced divider reads. (Meth 3)

Any OTSM build must have separate builds for 1S and LDO.

 

Flintrock
Offline
Last seen: 1 year 8 months ago
Joined: 09/10/2016 - 20:29
Posts: 1544

 Build details explained

 

 

Several preconfigured builds are included. Many represent rebuilds of older
versions.  Level of testing varies widely but many of the features included in
the builds are tested (a few aren't yet).  All builds now include the new thermal control method.  Most now include powersaving (Noah's torch: 40 days and 40 nights of moon mode).

default: This has no gauranteed setup. Probably will remain a Tripple build and
may have new features come and go.  It's purpose is to be THE definitive
baseline configuration file, including all the latest build options (although
some will be commented out, but still there).  If starting a new configuration
from scratch or studying the options, this is the one to look at.

II.1    attiny13 compatible builds (will auto build for attiny13 and above)

biscotti-HD:
 Based on TK's biscotti,
 Target layout: nanjg105D, 1-channel FET only
 Limitations:
          Very minimal, no OTC, no med press, noreverse, no hidden modes,
          no muggle, no moon.
 Features:
          Includes turbo-timeout/bump-up in attiny13.
          3 strobes, 4-bar battcheck, LVP, OTC-less short-press detection.
 HD Features:
          Original biscotti included no thermal or turbo-timeout.
          Extra room in HD allows TURBO timeout/bump up (like BLFA6) in attiny13,
          or the new bistro-HD thermal step-down in bigger attiny's.
          Corruption protection for OTC-less press timing makes clicks more
          reliable.  (SAFE_PRESSES)      
 Modgroups: 
          13 modegroups including strobe groups and reverse to make up for
          minimal features.
 Notes: There is no reason a BLFA6-emu-like  build cannot be constructed for a
          convoy board layout.

battcheck-divider: flashes adc channel for voltage read from divider using 1.1V
       internal reference.


        attiny25 compatible builds (everything els):

BLFA6_EMU-HD
  Mimics BLFA6_emu code, but configurable with any bistro-HD features.
  Target layout: BLFA6 2-channel FET+1, but doesn't fit on attiny13
                 Only for attiny25 and higher.
  Limitations:
          battcheck is "only" 8-bar version (by tradition), No OTSM in default
          config (but can be for attiny25+)
  Features:
          Almost full bistro features: OTC, medium clicks, reverse, hidden, muggle,
          moon. 8-bar battcheck. Temp calibration in attiny25+
  HD Features:
          Includes TURBO timeout/bump up (like original) in attiny13, or new thermal
          step-down/bump-up in bigger attiny's.       
 
  Modegroups: Very simple, only 2 groups included, 7 modes and 4 modes.
      Strobes and turbo are in hidden modes.
  
  
classic-HD
  HD version of classic bistro 
  Target layout: BLFA6 2-channel FET+1, only for attiny25 and higher.
  Limitations: No OTSM in default config (but can be)
  Features:  
          Full-featured: OTC medium clicks, reverse, hidden, muggle,
          moon. Volts+tenth battcheck.
  HD Features:
          Bistro-HD thermal step-down.
         
  Modegroups: 10 modegroups, from 1 1o 6 modes, including strobe groups.
      Strobes and turbo in hidden modes.  

trippledown-HD
  Essentially identical to classic but configured for a TA 3-channel
  FET+7135s+7135 board. Uses original bistro tripple-down modes.
 
TAv1-OTC-HD
  Essentially identical to classic but configured for a TA 3-channel
  FET+7135s+7135 board, and TA's extended modegroups.  v1 refers to version 1
  of the TA boards.
  Modegroups:
             Includes TA's v1.3 modegroups, 26 modes in all including a two
             added by me (HD has room for more)
             See Tav1.3+ modegroup listing in Apendix below.
  HD Features: As all before uses new thermal control.
              Benefits from added space to get a couple of new modes.
            
TAv1-OTSM-HD
  The flagship build. OTSM Uses large cap to run timer during power-off,
  creating reliable, stable click-timing.  
 
  Target layout: TAv1 tripple with OTSM components (see details in manual),
    1S only for this build.
 
  Otherwise the same as TAv1-OTC, but uses "internal" (inverted) Vcc voltage
  reads.  This generally does not require calibration to be pretty close to
  right.
  HD Features: OTSM, Vcc read, HD thermal control

TAv1-OTSM-LDO-HD
  Same as TAv1-OTSM-HD, but uses vcc-referenced divider reads needed for OTSM
  in builds >1S.  Works on LDO or zener builds if appropriate diode (or high
  quality LDO) is used.
  HD Features:  OTSM, vcc-referenced divider reads, HD thermal control.


      highly experimental builds
 
e-switch-noinit-HD:
  This is an experimental build for e-switch support.
  Layout: TAv1, 1-S or LDO, no OTC, standard TA divider
  Features: standard bistro with TAv1.3+ modegroups
  HD features: Eswitch, HD thermal control.
  Note: almost completely untested 
   
dual-switch-OTSM-HD:
  This is an experimental build for dual switch, e-switch plus click switch,
  with OTSM timing for the click switch.
  Layout: TAv1, 1-S only version, OTSM parts, no OTC
  Features: standard bistro with TAv1.3+ modegroups
  HD features: Eswitch, HD thermal control,
    adds dual-switch-noinit: Enables noinit timing control on clicky switch in
    a dual-switch light.
  Note: completely untested, Use the highest reccomended OTSM divider resistors
  (or try a bit higher) to reduce drain during e-switch off.  With 4kOhms ,drain
  will be around 1mA which is about 120 days of power from a 3Ahr battery, but
  voltage drops continuously over that time. Power it off with the
  click switch when shelving it.

dual-switch-noinit-HD:
  This is an experimental build for dual switch, e-switch plus click switch,
   with no timing cap on the click switch.
  Layout: TAv1, 1-S or LDO, no OTC, standard C2 is fine (not OTSM), standard TA divider
  Features: standard bistro with TAv1.3+ modegroups
  HD features: Eswitch, HD thermal control,
    adds dual-switch-noinit: Enables noinit timing control on clicky switch in
    a dual-switch light.
  Note: completely untested

dual-switch-dumbclick-HD:
  This is an experimental build for dual switch, e-switch plus click switch,
   where click-switch does nothing (no mode change), light comes back on as it
   was, like a long press with mode memory.  Especially useful if e-switch is
   set to not use mode memory, best of both.  Requested by Lexel.
  Layout: TAv1,  1-S or LDO, no OTC, standard C2 is fine (not OTSM)
  Features: standard bistro with TAv1.3+ modegroups
  HD features: Eswitch, HD thermal control,
    adds dual-switch-dumbclick: Overrides all mode changes if click switch is
    press--> just turns light off, and back on as it was.
  Note: completely untested

dual-switch-turboclick-HD:
  This is an experimental build for dual switch, e-switch plus click switch,
   where click-switch always goes to TURBO
  Layout: TAv1,  1-S or LDO, no OTC, standard C2 is fine (not OTSM)
  Features: standard bistro with TAv1.3+ modegroups
  HD features: Eswitch, HD thermal control,
    adds DUAL_SWITCH_TURBOCLICK: click switch always goes to first hidden mode
    (TURBO in this case).
  Note: completely untested.  Likely non-sensical, eswitch needs low leakage
  but OTSM needs fast leakage, probably 1mA anyway. 


4-channel-dual-switch
  This is an experimental build for dual switch, and 4 pwm channels
  Really it's just a rediculous concept demonstration config to prove how much stuff
  can compile and still fit in an attiny25.  The concept was actually tested a
  little at some point though, with 4-channels certainly working, but calling it
  experimental is an understatement.

  Layout: quadrupledown, 1-S only, OTSM cap and parts,
          4th PWM channel on OTC pin. E-switch and click switch both detected
          on voltage pin.
  Features: standard bistro with TAv1.3+ modegroups
  HD features: Eswitch, OTSM, 4th-channel PWM, internal Vcc read, HD thermal control
  Modegroups: Presently it's actually just setup with the 3-channel modegroups of
     TAv1.3+, so it's not really even using PWM4.  It would need customization.
  Note: almost completely untested, would need a separate build for LDO version
  (because it uses OTSM).

 

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 2 hours 1 min ago
Joined: 01/12/2013 - 14:40
Posts: 9804
Location: (469219) 2016 HO3

Have you tried 4-channel PWM on hardware?

I got it working in FSM, but the 4th channel is inverted and I haven’t found quite the right tweaks yet to un-invert it.

Flintrock
Offline
Last seen: 1 year 8 months ago
Joined: 09/10/2016 - 20:29
Posts: 1544

Yes, I tried it, although I don't promise that it works in precisely the latest build combination, but the code for it should be fundamentally fine.  Yes I definitely had inversion problems at certain stages of developing a solution at least. This is precisely one of the biggest cases the simulator came in very very handy.  You can step through tick for tick and watch what the timer ramps and matches are doing and see when the interrupts get called, and watch your portb values.

I don't recall all the details now, maybe it will come back to me.  Just looking quickly at my code, it seems I set portb on compare match, and clear portb on max.  That does sound pretty backwards and even seems contradictory to my not very clear comments for the interrupts, and I kind of recall being temporarily((and now again) confused by this.  I'll see if I can get a chance to run the simulator in the next few days and try to remember what's going on.

 

Mostly unrelated, but the biggest problem in the end was getting the light to shut off.  Again I forget the details, but there is some delay or jitter in the interrupt calls that makes full off not happen.  So I passed a global (actually a general purpose register bit, to facilitate streamlined assembly interrupts) to the interrupt handlers that disabled them entirely for mode 0.  I didn't test extremely low modes extensively.  As I recall the timing error on the simulator was around 6 timer ticks, but the simulator runs I think at 1MhZ, so one could hope that's about 1 tick in the real world.

 

Wish I could remember this better, might soon.

Flintrock
Offline
Last seen: 1 year 8 months ago
Joined: 09/10/2016 - 20:29
Posts: 1544

I do seem to recall that my timer is counting down, not up, and that does explain the backwardness.  The thing I don't remember is why it's counting down.  I think this is configurable right? So did I configure it backwards for a reason?  I don't recall.

 

Update: Well, I just ran the simulator, and it's definitely counting up (and the manual says it should).  So ... hmm..   So let's define the question better.  Did you copy my implementation and that's inverted or did you re-implement it and yours is inverted?  I've got a test rig read to flash and can test this again very quickly as soon as I get to it.  It turns out I'd forgotten, but the modegroups included do include a 4th pwm for testing still,  so it's ready to test as is.  I'll give a shot again soon.

 

In the end though, if it's inverted, reversing the interrupts is clearly the cure.

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 2 hours 1 min ago
Joined: 01/12/2013 - 14:40
Posts: 9804
Location: (469219) 2016 HO3
Flintrock wrote:
So let’s define the question better.  Did you copy my implementation and that’s inverted or did you re-implement it and yours is inverted?

I implemented it last month sometime, and didn’t know you had one until yesterday. I’ll have to check how yours works and see if it resolves the issue I ran into. The inversion isn’t really a problem though; it’s just inconsistent compared to the other three channels. A bigger problem is that the lowest few levels appear less stable, but it sounds like you ran into something similar with inconsistent timing.

For my purposes it’s still fine… but if there’s a way to improve it I’d like to do so.

Pages