Adventures in TinyAVR 1-Series

276 posts / 0 new
Last post
HarleyQuin
HarleyQuin's picture
Offline
Last seen: 10 months 3 weeks ago
Joined: 03/29/2013 - 04:47
Posts: 588

Thanks gchart, I hadn’t figured these WOx parts.
I’m still not sure what’s needed to setup a simple PWM-output with all this waveform-output/n-Ramp/configuration stuff. But I took a deep breath and did some datasheet diving. I smiled when you wrote you study datasheets for the fun of it… this is a different beast than the 13A.

It seems for the 1616 there is a newer (2020) datasheet than the one you took the pictures from. I noticed the difference in the PortC, where they aren’t digital only (blue) any more but analog (green) instead.

Again, my goal atm is to figure out which pins to connect where on a PCB. For years now it was very straight forward with the 13A/25/85 and its 6 usable pins. Now we have a lot more options, although the multiplexer is less flexible than I initially thought.

So this is my take for now when it comes to the pins. I’d be very happy if errors get corrected and blanks get filled.

Timer/Counter D for PWM
I really like the idea of low power pwm-channels. 2 channels are sufficient for most drivers. 12-bit makes for 16 times the pwm resolution, 10-bit already quadruples it.

The 2 TCD channels WOA and WOB are wired to PA4 and PA5 (and could be mirrored to PC0 and PC1, but that doesn’t seem neccessary).
I found the (output-)compare-register CMPASET and CMPBSET, but can only assume that less than 12 bit are done with the counter prescaler CNTPRES and/or the synchronization prescaler SYNCPRES.
I have no idea what kind of ramp/slope waveform stuff we need.

Other T/C for PWM
Timer/Counter A with 3× 16-bit is wired to PB0, PB1 and PB2, 6× 8-bit would be PB0, PB1, PB2, PA3, PA4 and PA5.
Again, remapping does not seem neccessary (all 6 can only be remapped on a 24 pin MCU anyway).

Timer/Counter B only allows for 8-bit pwm (16-bit counter, but only 8-bit pwm according to datasheet). Still, I’m curious why Timer/Counter A is referred to as “TCA0” and Timer/Counter B as “TCBn”.

But it seems Timer/Counter A will fullfil most needs for pwm channels if the 12 bit or the 2 channels of Timer/Counter D are not enough.

ADC operation
In the past this is what we used for voltage monitoring and the off-time-capacitor.
It seems almost any pin can be configured as ADC input here if needed. PA1, PA2, PA6 and PA7 look preferable as they would not interfere with pwm-channels.

AUX LED (indicator LED) and
Switch pin
I need a heads up here from you guys:
The switch pin needs to recognize when pulled to ground (configured as input).
The aux leds are powered by configuring the pin as output and setting as high.

Is this (both) possible with all 17 usable pins (I dont count vcc, gnd and udpi) or are there any limits to certain pins?
At first glance, PC0, PC1, PC2 and PC3 would be my first choice.

Again, thanks a lot
HQ

Oshpark Boards:
HQ ProgKey: Universal Driver Programming Key . Boost: HQ 15mm/17mm programmable boost driver with ATtiny13A
46mm Triple-Channel: BLF SRK FET v3 . 17mm Linear: HQ10D / HQ4D / HQ4S . Contact Boards: 22/24/26mm

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

HarleyQuin wrote:
I would very much like to have the possibility to have more resolution for PWM. Especially in the moon region and at the seams of the PWM channels.

If I read the datasheet right the 1616 supports more than 8 bit PWM, that would be THE argument for me to migrate.

It’s worth mentioning that increasing PWM to 16 bits also means decreasing the pulse speed by a factor of 256. Instead of 15.625 kHz at a clock speed of 8 MHz, it would be just 61 Hz. So that can be kind of a problem.

However, there are some other ways to increase the resolution… especially on the low modes:

  • Add a low-mode power channel at like… 20 mA or so. Or maybe 40 / 50 / 80 mA. Then the step sizes will be much smaller at the bottom of the ramp. Like, at 20 mA, each step would be about 0.03 lm.
  • Instead of 16-bit PWM, maybe use a PWM+DSM hybrid. This would get the in-between levels by rapidly switching between two adjacent PWM levels, using an interrupt tied to the pulses. This allows it to use 16 kHz 8-bit PWM but get several extra bits of resolution.

About the first option, it’s relatively straightforward if there’s room on the PCB. It can also be combined with a higher regulated power channel, using the low channel to provide extra resolution between every two high-channel steps. To do this well though, you’d need a power-of-two relationship between the two power channels… like 20mA and 5A, since that’s about 256X.

About the second option, Inferion did it on the YLP Unicorn and it worked well. I also rewrote the entire interrupt system in FSM in order to make PWM+DSM theoretically possible in the future, though I haven’t actually tried it yet.

Anyway, increasing the analog resolution is probably the best option… but if it must be digital, at least there’s a potential way to do it without sacrificing pulse speed.

HarleyQuin
HarleyQuin's picture
Offline
Last seen: 10 months 3 weeks ago
Joined: 03/29/2013 - 04:47
Posts: 588

Hi TK,
thanks for weighing in (and just here and now: thanks for your wonderful FSM/Anduril).

Admittedly I’m very keen on gchart’s “Test 15” in his post http://budgetlightforum.com/comment/1619872#comment-1619872

32 kHz
TCD, 10 bit
20 MHz
19.53 kHz
970 uA

10-bit at 20 kHz with 1mA looks like the sweet spot.

Last summer I spent some time to improve the ramping table for a 1+12 7135 driver. With a luxmeter and handmade graph I got the step between 1×7135 and Nx7135 virtually invisible, so I could get rid of the intermediate blink. I understand why this can’t be done on a commercial driver and the intermediate blink is a very ingenious cover (especially for FET+1 drivers). But it’s so, sooooo marvellous to have a nice and smooth ramping all over the range, it was so much worth the effort.

But on the lower end it has still room for improvement with either very visible steps (doubled or tripled pwm values) or it is too steep. 10-bit would smooth this curve very nicely.

From a driver design perspective this could be done with still 2 pwm channels and this might be preferable for smaller drivers and to minimize the numbers of pwm seams.

But I’m sure a change to the Attiny 1-series will introduce a lot of possibilities for a variety of drivers so admittedly I’d be just happy if we can get this going with the basic stuff (2x pwm, some aux, a switch) and improve from there.

Oshpark Boards:
HQ ProgKey: Universal Driver Programming Key . Boost: HQ 15mm/17mm programmable boost driver with ATtiny13A
46mm Triple-Channel: BLF SRK FET v3 . 17mm Linear: HQ10D / HQ4D / HQ4S . Contact Boards: 22/24/26mm

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

HarleyQuin wrote:
I’m very keen on gchart’s “Test 15” in his post http://budgetlightforum.com/comment/1619872#comment-1619872

32 kHz
TCD, 10 bit
20 MHz
19.53 kHz
970 uA

10-bit at 20 kHz with 1mA looks like the sweet spot.

Last summer I spent some time to improve the ramping table for a 1+12 7135 driver. …
But on the lower end it has still room for improvement with either very visible steps (doubled or tripled pwm values) or it is too steep. 10-bit would smooth this curve very nicely.

Yeah, it’s helpful to add bits without slowing the pulse speed. However, there are still limitations there, and the limitations matter at moon levels.

With a single 7135 chip, the steps are typically about 0.6 lm apart. When using 10 bits instead of 8, it drops to 0.15 lm… but that’s still pretty coarse for really low levels.

The other limitation is that there is a lower bound to the pulse length. It depends quite a bit on the individual hardware, and varies a lot from one item to another, but moon doesn’t work at all if the pulses aren’t long enough for the 7135 chip to turn on and the LEDs to light up.

If I run things at 16 kHz, I typically have to set the PWM level to about 3 to 10 in order to get any light to come out. The exact number is unpredictable because it varies a lot even between identical lights. NarsilM worked around this by letting the user set the PWM level for moon directly. Anduril works around it by slowing the pulses down to reduce sensitivity to small changes in hardware. Adding extra digital resolution and decreasing MCU power would help somewhat, but it would still need a way to compensate for random variations in hardware response curves.

If possible, it’s much more effective to use a lower power channel. Regulating a big power channel to just 0.1% of its capacity using digital techniques is like trying to fill a thimble with a fire hose. It would be a lot easier to just use an eye dropper.

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

Oh, er, if it helps, I recently put some ideas into the form of a diagram while proposing some driver upgrades for the Noctigon KR4 / KR1. I’m hoping Hank will be able to fit a third power channel, regulated to 1/256th (or maybe 1/128th) of the level of the middle power channel.

The top row shows two existing designs and the third one I proposed. The bottom row shows why the third channel needs to be regulated instead of just a resistor. However, the “just a resistor” approach could still work if it’s stacked underneath like a 7135 chip instead of filling in between steps.

gchart
gchart's picture
Offline
Last seen: 11 hours 14 min ago
Joined: 03/19/2016 - 11:57
Posts: 3158
Location: Central IL

HQ, without checking into each specific pin, what you have laid out looks correct. There are many pins capable of PWM. Almost any pin can be used for ADC. Any pin can be used for Aux & Switch (well, outside of VDD, GND, and UPDI/Reset).

Side note about voltage sensing: you can directly sense voltage from the VDD pin with good accuracy, assuming you don’t have an LDO in front of it. Whereas the attiny85’s internal VREF was +/- 10%, the 1-Series VREF is +/- 2%.

Side note 2: also unlike the attiny85, the 1-Series chips have factory-calibrated temp sensing. The factory calibrated values (slope and offset factors) are stored in TEMPSENSE registers and seem to be pretty accurate.

gchart
gchart's picture
Offline
Last seen: 11 hours 14 min ago
Joined: 03/19/2016 - 11:57
Posts: 3158
Location: Central IL

And TK is (of course!) spot on. Going to a higher resolution PWM can be nice, but it doesn’t necessarily fix things in the low end of the spectrum because of the length of time that some of these chips (like the AMC7135) need to be turned on to function properly.

I like where you were going TK with the resistor for smoothing out the ramp. Slightly different, but I’ve seen a few drivers lately that use a resistor for their moonlight channel (non-PWM).

Another option would be to add an adjustable linear regulator like one of these:

  • AMC7136 (10mA – 400mA, internal FET)
  • QX7138 (20mA – 3A, external FET)
  • CN5710 (60mA – 1A, internal FET)
  • OC7141 (10mA – 3A, external FET)

In addition to being able to PWM these chips, you could employ a FET that effectively adds/removes resistance on the current sense pin to vary the current that it’s controlling to. That would allow us to use a single linear regular with varying levels of current output even before you start PWM’ing the thing (you could vary the current sense resistor AND use PWM to get a wide range of effective currents). This is nicely illustrated in the CN5710 datasheet

HarleyQuin
HarleyQuin's picture
Offline
Last seen: 10 months 3 weeks ago
Joined: 03/29/2013 - 04:47
Posts: 588

@gchart
Thanks, that is quite assuring.

I don’t use ADC for voltage monitoring on the 85 anymore. But there was recent talk that it might be useful or better to revert to a voltage divider. Don’t know where I read it or who wrote it. That’s why I took it into consideration. Just trying to get an overview of the possibilities of the 1-series.

And the temp sensing calibration, yes I saw and liked this. In Anduril I overrode the temp offset for known drivers for not having to recalibrate it after every new flash. And I reflashed a lot since having the progkey.

So yes, I’m pretty stoked when it comes to the 1-series. I will now look deeper into your firmware, especially the test firmware, and cross reference the datasheet to get a better grip on it.

.

@TK
I’m not talking lowest moon. I wanted to hint where my interest is and used a brief and thus inaccurate description. I will elaborate below, but this leads away from my real question:

Which function should be connected to which pin?

I need a start to make me a driver that I can use for playing around – without having pins connected blatantly wrong, e.g. unusable.

I got the impression that nothing evolved in the support of this MCU because there was no firmware for it, which might be because there was no driver for it, which again might be because there was no firmware for it…

So tell me what hardware you need at which pin. That’s still my basic question here and I will happily design you a driver and/or troubleshoot firmware.

.

Now to PWM.
With the good 7135 ravenclaw I get consistent lowest light with phase correct pwm level 2 at 18kHz. That’s lower than I need or like. I buy them at lcsc.com and bin them for use as 1×7135 at 348-352mA. That makes them incredibly consistent at all pwm levels.

What I care for is about the lower fifth of the ramping table.
Unfortunately I can’t give a picture, as I’m on holiday with a linux laptop, crappy internet and no password for imgur…

#define PWM1_LEVELS 4, 4, 4, 5, 5, 5, 6, 6, 6, 7, 7, 8, 8, 9, 9,10,10,11,11,12,12,13,13,14,14,15,15,16,16,17,17,18,18,19,19,20,20,21,22,22,23,24 ,25,26,26,27,28,29,30,31,32,33…

The lower parts are of course not a curve but a series of linear segments with flat parts and increasing gradient. It’s still either stuttering or gets too bright too fast. I already shortened the lower parts, they were more like 4, 4, 4, 4, 4, 4, 4 when they came out of the python script (after a lot of testing I liked the 7th function best and this leads to a flat start).

I’m still very sure that this will benefit from an increased bitrate. 10-bit alone will be very beneficiary, as it gives 3 additional values inbetween any 2 present ones.

Oshpark Boards:
HQ ProgKey: Universal Driver Programming Key . Boost: HQ 15mm/17mm programmable boost driver with ATtiny13A
46mm Triple-Channel: BLF SRK FET v3 . 17mm Linear: HQ10D / HQ4D / HQ4S . Contact Boards: 22/24/26mm

gchart
gchart's picture
Offline
Last seen: 11 hours 14 min ago
Joined: 03/19/2016 - 11:57
Posts: 3158
Location: Central IL

A word of warning, HQ… I’ve built a few drivers around this and in general, I’ve been very pleased. But if you’re going to use these with a clicky switch, you’ll likely need to use an OTC to measure offtime. While the “noinit” trick technically works, I’ve seen it take upwards of 45 minutes for the variables with “noinit” to decay; not very useful for what we need (Mike C has also observed this). For e-switches, this isn’t a problem.

  • UTorch UT01
  • 17mm 3A Linear (NOTE: I built this expecting to use NOINIT… so it doesn’t work well for clickies as its built. You could probably shoehorn an OTC onto it though. Or tie a e-switch wire to a free pin.)
  • Dev board (NOTE: don’t use this in dual-channel config, I skipped using FETs and it doesn’t work out to power the same LED from 2 pins alternating without having them be isolated by a FET or diode or something Facepalm )
  • Emisar D1S 5 amp linear driver

I’ve got a few others around, but that’s the most of it

HarleyQuin
HarleyQuin's picture
Offline
Last seen: 10 months 3 weeks ago
Joined: 03/29/2013 - 04:47
Posts: 588

Yes, I only have plans to start with momentary.
I was designing a new driver for my 2 Yezl Y3, removed the 85, inserted a 20 pin QFNL and liked what I saw LOL

Oshpark Boards:
HQ ProgKey: Universal Driver Programming Key . Boost: HQ 15mm/17mm programmable boost driver with ATtiny13A
46mm Triple-Channel: BLF SRK FET v3 . 17mm Linear: HQ10D / HQ4D / HQ4S . Contact Boards: 22/24/26mm

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

gchart wrote:
Another option would be to add an adjustable linear regulator …
  • QX7138 (20mA – 3A, external FET)

In addition to being able to PWM these chips, you could employ a FET that effectively adds/removes resistance on the current sense pin to vary the current that it’s controlling to. That would allow us to use a single linear regular with varying levels of current output even before you start PWM’ing the thing (you could vary the current sense resistor AND use PWM to get a wide range of effective currents).

The BLF GT used a similar solution… but instead of a linear regulator, it used a buck regulator. The top 15/16ths of the ramp used current control, and the bottom 16th used PWM at 1/16th power. It worked really well.

We tried to use a 7138 chip at one point, but the results weren’t great. It could regulate both ends of its range, but the response curve between wasn’t a useful shape. So that driver design got scrapped.

gchart
gchart's picture
Offline
Last seen: 11 hours 14 min ago
Joined: 03/19/2016 - 11:57
Posts: 3158
Location: Central IL

The Convoy H1 uses the 7138. I’ve got the D4 V2 UI running on it and I love it. But the problem I see with it is the max PWM speed spec is 10 kHz which I’m sure some BLF’ers would complain about.

Do you know what Hank’s 5 amp drivers are using? Op-amp controlling a FET in its linear region?

If it would help get these chips off the ground, I’d be glad to design a great driver around them. But I’m not an expert when it comes to some of this EE stuff so it helps to reference specific chips or at tested designs, etc. I’d do a simple FET + 1×7135 but it seems like people feel that’s not good enough anymore.

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 16 hours 17 min ago
Joined: 01/12/2013 - 14:40
Posts: 10759
Location: (469219) 2016 HO3
HarleyQuin wrote:
I got the impression that nothing evolved in the support of this MCU because there was no firmware for it, which might be because there was no driver for it, which again might be because there was no firmware for it…

Yes and no. I didn’t make firmware for it, but gchart did… so most of the work is already done.

http://www.ghart.com/blf/firmware/

Merging that in is still on my todo list, because I’m slow. I really should do that soon, before my branch diverges too much.

HarleyQuin wrote:
What I care for is about the lower fifth of the ramping table.

#define PWM1_LEVELS 4, 4, 4, 5, 5, 5, 6, 6, 6, 7, 7, 8, 8, 9, 9,10,10,11,11,12,12,13,13,14,14,15,15,16,16,17,17,18,18,19,19,20,20,21,22,22,23,24 ,25,26,26,27,28,29,30,31,32,33…

The lower parts are of course not a curve but a series of linear segments with flat parts and increasing gradient. It’s still either stuttering or gets too bright too fast.

Yeah, extra resolution would definitely be nice for the bottom of the ramp.

I’ve tried a bunch of methods to increase the resolution. Some worked, some didn’t. And some worked on my test host, but failed when installed on another light.

The most effective and reliable methods I’ve tried were the ones which increased resolution in an analog domain. Sometimes digital works, but it’s a lot more prone to failing. This is mostly because the analog components have an inherent noise floor, and no digital solution can increase resolution below that noise floor. When approaching that limit, it’s necessary to lower the noise level in order to make the signal more precise.

Like, let’s say a ramp can go from 1 to 10000, and there is a noise component of +/- 10. Toward the top of the ramp, let’s say it’s at level 9000, it doesn’t really matter if it varies from 8990 to 9010. But toward the bottom at level 100, going from 90 to 110 is probably visible… and even lower at a level of 15, varying randomly from 5 to 25 makes the signal basically unusable.

But give it a second analog path with everything scaled down to 1%, and we get something which can go from 0.01 to 100, with a noise component of +/- 0.1. Now level 15 is a lot more stable, varying only from 14.9 to 15.1.

It’s not always feasible to do this, due to space constraints on the driver… but when possible, it’s almost always the most effective solution.

Er, it might also be worth mentioning that the “noise” isn’t necessarily visible within a single light. Sometimes it’s visible, like the flicker seen at low levels on the KR4, but I’m also talking about the variation within a production run. Produce a thousand items, using a dozen different types of LEDs, and there will be a lot of variation. At the bottom edge of its output range, some items will work great while others don’t light up at all. So I’m mostly trying to stick to solutions which work for the whole batch, not just individual items.

In the case above, that often means that an individual light has a range of 1 to 10000, but the +/- 10 part is a static property of that light. Like… it’s always +5 or it’s always -7. So toward the bottom of its range, I could calibrate the ramp so it looks perfect on my +5 sample, but then when the same code runs on a -7 sample, it looks all wrong. I might set the ramp to start at “4,4,4,5,5,5,6,6,6,7,7”, but on another item it ends up looking like “0,0,0,0,0,0,0,0,0,1,1”.

HarleyQuin wrote:
I liked the 7th function best

If it helps at all, the exponent option can be an arbitrary number. Like, if “seventh” is close but not quite right, try giving it 6.9 or 7.03 to fine-tune it.

Anyway, I don’t have answers for Tiny1 circuit design, so I’m not helpful here… but I’d definitely recommend reading through gchart’s code if you haven’t yet.

HarleyQuin
HarleyQuin's picture
Offline
Last seen: 10 months 3 weeks ago
Joined: 03/29/2013 - 04:47
Posts: 588

ToyKeeper wrote:
Yes and no. I didn’t make firmware for it, but gchart did… so most of the work is already done.
Hmmm… No.
It’s nice of you being so modest, but it’s not a thing until FSM supports it Wink

.

ToyKeeper wrote:
… but I’m also talking about the variation within a production run. Produce a thousand items, using a dozen different types of LEDs, and there will be a lot of variation.
I totally understand that. I did a lot of measuring, for example to see how different 7135 behave in which condition with which LED and which firmware settings. I settled with a specific hardware and firmware for my bread-and-butter clicky lights. But this includes handpicking not only the 7135 but also all capacitors. The result is totally worth it. I get consistent brightness levels and OTC timing without need for calibrating. But that works as a hobby, for gifting some lights, and just having fun in DIY. Not in a large scale production.

.

ToyKeeper wrote:
If it helps at all, the exponent option can be an arbitrary number. Like, if “seventh” is close but not quite right, try giving it 6.9 or 7.03 to fine-tune it.
The fine tuning I did by hand. Wrote me a ramping table test state in Anduril to check the critical parts of the table on a step by step basis. The result puts a smile on my face every time I use this light. Again, this obviously does not work on a production scale.

.

ToyKeeper wrote:
Anyway, I don’t have answers for Tiny1 circuit design, so I’m not helpful here…
Don’t worry. My following post is for the others here. Smile
But when you ever come to the point that FSM supports the 1-series, I want to be helpful myself, have some drivers ready and provide some testing.

Oshpark Boards:
HQ ProgKey: Universal Driver Programming Key . Boost: HQ 15mm/17mm programmable boost driver with ATtiny13A
46mm Triple-Channel: BLF SRK FET v3 . 17mm Linear: HQ10D / HQ4D / HQ4S . Contact Boards: 22/24/26mm

gchart
gchart's picture
Offline
Last seen: 11 hours 14 min ago
Joined: 03/19/2016 - 11:57
Posts: 3158
Location: Central IL
HarleyQuin wrote:
ToyKeeper wrote:
Yes and no. I didn’t make firmware for it, but gchart did… so most of the work is already done.
Hmmm… No. It’s nice of you being so modest, but it’s not a thing until FSM supports it Wink

Well yes… and no. The updates haven’t been merged into TK’s repository yet, but the link that TK shared leads you to my updates that integrate 1-Series support into FSM. I have it up and running on Sofirn SC31B (just because I have a few sitting around and it made a decent host) via a PIC-to-ATTYINYx16 adapter board.

I also just threw together a 20mm FET+1 driver and updated programming key. I’m still waiting on the boards to arrive. The programming key is nearly identical to my old one, but I decided it was better to switch around the Gnd and Rst positions (mainly to avoid frying the chip if you reverse the key and also because it works better with PCB layouts).

Scallywag
Scallywag's picture
Offline
Last seen: 5 hours 36 min ago
Joined: 01/11/2018 - 22:23
Posts: 2058
Location: Ohio, United States

First, it’s cool to see HQ in here after checks notes 19 months between posts.

gchart wrote:
The Convoy H1 uses the 7138. I’ve got the D4 V2 UI running on it and I love it. But the problem I see with it is the max PWM speed spec is 10 kHz which I’m sure some BLF’ers would complain about.

Do you know what Hank’s 5 amp drivers are using? Op-amp controlling a FET in its linear region?

If it would help get these chips off the ground, I’d be glad to design a great driver around them. But I’m not an expert when it comes to some of this EE stuff so it helps to reference specific chips or at tested designs, etc. I’d do a simple FET + 1×7135 but it seems like people feel that’s not good enough anymore.

I’m not much use in this thread – but I wanted to comment on the 10kHz PWM. Nobody can see that. They can find ways to measure it and show that, but it will never be visible to human eyes. The only issue you’ll run into is if something ends up making a 10kHz tone, which all but the oldest of us will be able to hear. I don’t fully understand why PWM is occasionally audible in lights, but that’s my take. Also, you can get away with a lot slower PWM if the signal’s waveform also has a DC component.

HarleyQuin
HarleyQuin's picture
Offline
Last seen: 10 months 3 weeks ago
Joined: 03/29/2013 - 04:47
Posts: 588

Now I need to get me the hardware.

I’ll go with the 416 xplained nano board after looking at the options. With ~8€ it’s cheap enough not to try my luck with the AliExpress stuff. I will need to upgrade to a newer AVR studio, though.

.

One question still:

Which Attiny1616 do I need, MFR or MNR?
Their own datasheets are inconclusive, as they stated the specs differently. The 2020 datasheet version says

ATtiny1616-MNR 16 KB/2 KB 20 20 MHz 1.8V to 5.5V VQFN -40°C to +105°C
ATtiny1616-MFR 16 KB/2 KB 20 16 MHz 2.7V to 5.5V VQFN -40°C to +125°C

Why does the MFR type only support 16MHz?
Mouser/Farnell list both versions as 20MHz. Does the MFR support 20MHz at least below 105C?

.

@gchart
I’m not a firmware pro. I can do stuff where I want and need to, it just takes me a lot of time. I’ll be patient and wait for the official integration.

ProgKey: swapping the pins (grd to the center) looks perfect as the pins inbetween, PA1-PA3, might not be as relevant to us and then the routing falls into place almost by itself.

.

@Scallywag
time surely flies

.

Just for the fun of it: I did some quick-and-dirty board sketching (changing the MCU on existing brds) and it will work out nicely. Yes, the routing is different as we no longer use space under the MCU or between the pins. But there is a lot of space around the MCU now, especially compared to the 85.

.

Oshpark Boards:
HQ ProgKey: Universal Driver Programming Key . Boost: HQ 15mm/17mm programmable boost driver with ATtiny13A
46mm Triple-Channel: BLF SRK FET v3 . 17mm Linear: HQ10D / HQ4D / HQ4S . Contact Boards: 22/24/26mm

loneoceans
loneoceans's picture
Offline
Last seen: 6 months 5 days ago
Joined: 01/08/2017 - 00:18
Posts: 283

Very exciting developments and many thanks to ToyKeeper, gchart, HarleyQuin for the work! Actually I've been recently working on a driver with 3 channels control just like what TK was talking about, using a buck regulator for most of the range, a separate channel for very low brightness levels, and finally one for FET, though practically speaking the lowest range doesn't need much resolution for brightness levels I think. 

www.loneoceans.com/labs/

- Next-gen Switching Drivers: Lume X1 and Lume1
- High Power Boost Drivers: GXB100 GAN 100W, GXB172 17mm 50W
- Older: GXF22, GFS16, GXB17 & GXB20

gchart
gchart's picture
Offline
Last seen: 11 hours 14 min ago
Joined: 03/19/2016 - 11:57
Posts: 3158
Location: Central IL

Thanks for popping in, loneoceans! I always look forward to seeing what you cook up Smile

Scallywag
Scallywag's picture
Offline
Last seen: 5 hours 36 min ago
Joined: 01/11/2018 - 22:23
Posts: 2058
Location: Ohio, United States

loneoceans wrote:

Very exciting developments and many thanks to ToyKeeper, gchart, HarleyQuin for the work! Actually I’ve been recently working on a driver with 3 channels control just like what TK was talking about, using a buck regulator for most of the range, a separate channel for very low brightness levels, and finally one for FET, though practically speaking the lowest range doesn’t need much resolution for brightness levels I think. 


I’m excited for development on low-brightness channels. So far the standard has mostly been a 1×7135 channel, and it does alright. I’d be most excited for an example of how to do it well that others could implement on their future designs
gchart
gchart's picture
Offline
Last seen: 11 hours 14 min ago
Joined: 03/19/2016 - 11:57
Posts: 3158
Location: Central IL

New 20mm FET+1 boards just came in and I assembled one today and threw it in a Sofirn SC31B. So far everything is working great. Thumbs Up

sorry, I hadn’t cleaned flux off yet

MRsDNF
MRsDNF's picture
Offline
Last seen: 2 months 5 days ago
Joined: 12/22/2011 - 21:18
Posts: 13473
Location: A light beam away from the missus in the land of Aus.

I admire your skills and abilities gchart. Well done.

 

djozz quotes, "it came with chinese lettering that is chinese to me".

                      "My man mousehole needs one too"

old4570 said "I'm not an expert , so don't suffer from any such technical restrictions".

Old-Lumens. Highly admired and cherished member of Budget Light Forum. 11.5.2011 - 20.12.16. RIP.

 

staticx57
Offline
Last seen: 12 hours 7 min ago
Joined: 04/11/2016 - 00:43
Posts: 713
Location: New Jersey, United States

Really nice work!

Tom E
Tom E's picture
Offline
Last seen: 7 hours 39 min ago
Joined: 08/19/2012 - 08:23
Posts: 14684
Location: LI NY

Outstanding! Any updates? I'm working with Anduril2 now. I assume that's a FET+1.

gchart
gchart's picture
Offline
Last seen: 11 hours 14 min ago
Joined: 03/19/2016 - 11:57
Posts: 3158
Location: Central IL

Tom E wrote:

Outstanding! Any updates? I’m working with Anduril2 now. I assume that’s a FET+1.


Well, not a whole lot to update on I guess. Driver works great, and Anduril is running well on it. I haven’t tried Anduril2 yet. Want to make sure it’s fairly stable before I mess with it.
ToyKeeper
ToyKeeper's picture
Offline
Last seen: 16 hours 17 min ago
Joined: 01/12/2013 - 14:40
Posts: 10759
Location: (469219) 2016 HO3
gchart wrote:
I haven’t tried Anduril2 yet. Want to make sure it’s fairly stable before I mess with it.

It’s getting pretty close. I probably would have merged it already, but I’ve been trying to get a bit more feedback first and am hoping to give it an updated diagram or two. However, there’s so much stuff to put into the diagram, it keeps either turning into a tangled mess or a reference table. So perhaps I should split it into several diagrams.

When every mode change required going through “off”, the diagram layout was much simpler. But with new shortcuts between a few different modes, I end up with lines crossing each other. It’s nice during use, but makes for a messy flowchart.

Tom E
Tom E's picture
Offline
Last seen: 7 hours 39 min ago
Joined: 08/19/2012 - 08:23
Posts: 14684
Location: LI NY

gchart sent me a fully populated 20 mm FET+1 1616 driver, a pogo pin cable assembly, and a XNANO 0416 dev kit. I was able to get Anduril running on it today:

  • created a AS 7 project for the 1616
  • plugged in gchart's Anduril/fsm source code
  • got the XNANO USB dongle board recognized by Windows (must use a good high qual USB-A to Micro USB-B that supports power data)
  • used AS 7 to program the driver via its Tools-->Device Programming method

It's working!

Temp calibration was Dead On!! I never saw this before with any Narsil/Anduril light, ever (gchart mentions it's accurate in the OP)

Now I have a working dev/test platform for this processor. Just have to get it in to a light for full testing.

 

 

gchart
gchart's picture
Offline
Last seen: 11 hours 14 min ago
Joined: 03/19/2016 - 11:57
Posts: 3158
Location: Central IL

Woohoo!

PS – I think you meant a USB cable that supports data. Many do not – they only have the power wires.

Scallywag
Scallywag's picture
Offline
Last seen: 5 hours 36 min ago
Joined: 01/11/2018 - 22:23
Posts: 2058
Location: Ohio, United States

gchart wrote:
Woohoo!

PS – I think you meant a USB cable that supports data. Many do not – they only have the power wires.


I’ve noticed that with a lot of “charger cables”, especially those that come included with cheap stuff. Bonus points if they’re super short (8 inches/20cm or less).
thefreeman
thefreeman's picture
Online
Last seen: 9 min 15 sec ago
Joined: 01/06/2020 - 09:56
Posts: 871
Location: France

Thank you for your great work gchart, I want to make a tint adjustable driver and I think I should go with those 1 series attiny. The 3 wires flashing, calibrated temp sensor, and fast higher resolution PWM all sound very good.

gchart wrote:
The Convoy H1 uses the 7138. I’ve got the D4 V2 UI running on it and I love it. But the problem I see with it is the max PWM speed spec is 10 kHz which I’m sure some BLF’ers would complain about.

Do you know what Hank’s 5 amp drivers are using? Op-amp controlling a FET in its linear region?

If it would help get these chips off the ground, I’d be glad to design a great driver around them. But I’m not an expert when it comes to some of this EE stuff so it helps to reference specific chips or at tested designs, etc. I’d do a simple FET + 1×7135 but it seems like people feel that’s not good enough anymore.

A bit late but here is the answer :

I’m a novice in EE too but I want to make an Anduril tint ramping driver and those 7135 wont do so I’m trying to learn.

To explain a bit, the signal from the MCU (attiny1634) is divided down to Rsense level (50mV for a 10mΩ Rsense and 5A) by R3-R4, and is filtered by R4-C3 and fed to the non inverting input of the Op Amp, output to the gate of the mosfet, and Vsense to the inverting input, creating a feedback loop which makes the op amp adjust Vgs of the mosfet to maintain both its input at the same voltage. Reducing the duty cycle on PB3 lowers the voltage at the op-amp’s Vin+, for example at 10% we get 5mV, thus the gate voltage is lowered to get Vsense at 5mV, so 0.5A.

C5 : I suppose it is a decoupling capacitor for the op amp VCC.
R6 : gate resistor.
R7 : gate-source resistor, I’m not sure it’s necessary here ? I thought it was needed to discharge the gate capacitance as fast as possible when switching. No switching here.
C4 : when I simulate the circuit without it there are massive current oscillations so I guess it’s to eliminate those, 100pF seems to be sufficient, the higher it is the slower the current is adjusted, especially at very low currents, I’m guessing this is why there is a turn ON delay at level 1 and 2 and maybe its value is too high and could be reduced to improve that (I just put some probable values for the capacitors on the schematic, I didn’t measure them)
R8 : looking for precision Op-Amp I came upon this page , the diagram mentions “resistor cancels out parasitic seebeck effect voltage”, so hmmm… probably that Glasses .

There is a 2.8V LDO (MIC5205) powering the MCU and the aux LEDs, and a second mosfet for the direct drive channel.

In the led4power driver there is a direct drive option with just one mosfet onboard so I’m guessing there is simply another signal from the MCU going to the gate of the mosfet, pulling it to high for direct drive. I don’t know if it ramps down from DD to CC with PWM, but in simulation PWM on the gate seems to cause some problems and only seems to work at low frequencies, it seems that the op amp feedback loop is not fast enough to respond each time DD is OFF. Probably why on the Noctigon there is a dedicated mosfet for DD.

I tested the opposite thing in simulation to achieve very low output, instead of pulling the gate to high, pulling it to low (a small nFET between the gate of Q2 and GND, controlled by another pin) when dimmed analogically at low output, say 10mA, even just 8bit PWM would give extremely low outputs, but again it only works at low frequencies unfortunately.

So the other way mentioned in the thread is increasing the resolution, it would help a bit, if it works in practice in this case because the voltages compared by the op amp become extremely low, 12uV at 12bit, the offset voltage of the TLV333 is 2uV(typ) 15uV(max) so it’s just really close. It would do 1.2mA, which is sublumen if we assume 3mA/lm.

Probably another channel is preferable, maybe just a resistor would do but current varies with the cell’s voltage, a low current PWMable CC linear regulator would be preferable, I see the ones you mentioned in another post but smaller packages would be better.

It would be great to have a BLF reference linear driver based on this design(noctigon, convoy, led4power), it’s more efficient than FET+n*7135 drivers while still not being as complicated/large as switching converters.

Anyway I’m basing my tint adjustable driver on this Noctigon driver, basically by putting two linear CC channel on it.

One question that have is about Timer/Counter D, when it says that there is one, does it means that only one of the 2 pins which can use it at a time, or is that not what it means at all ?

Pages