Tone with clock @ 1MHz sounds distorted/grainy

[kinesphere]

Hi Spence and all,

For the context, I was generating tones on an ATtiny85 at 1MHz (important for low power consumption) using a routine to make use of Timer 1 (to not affect 'delay') like this:

http://www.technoblogy.com/show?20MO

Now, I migrated to ATtiny1616 in my project and if I use tone from your library at 1MHz it sounds very grainy. I tried different timers in the Arduino tools and the best is the RTC, but still not as clean as playing in 4MHz and over.

Ideally, I would like to use the routine as before, but I'm not sure if it's possible to implement that code (I'm struggling to understand the datasheet for these new AVRs).

Any help would be much appreciated.

[SpenceKonde]

Hmm, well, I definitely didn't have low speed operation in mind when I (re)wrote tone. Your enemy in porting that code you have from the 85 is that there is that a type B timer doesn't have an independent prescaler, while the type A timer is almost all your PWM pins, and the type D timer, which is the best suited to making tones, is the most complicated peripheral on the chip (and is used by default for timekeeping when present, on the logic that it's the hardest to work with and people are least likely to repurpose it - but that's just a menu option to move to a different timer) and is only present on 1-series parts.

[kinesphere]

Thanks for the explanation Spence! I will study more about these timers and if there is no straightforward option I might just use 4MHz.

[ObviousInRetrospect]

any chance your project can have the MCU spend most of its time in SLEEP_MODE_STANDBY in which case the power consumption difference between 1Mhz and 4mhz may be negligible or the opposite of what you expect?

[ObviousInRetrospect]

You can't usefully run off a CR1616 without using sleep. Period. CR1616 is 90mAh. That's 535ua if you want it to last a week (10 for a year). I suspect you are above that at 1mhz.

You totally can wake from an interrupt fast enough for the user to not perceive it. Looking at the datasheet I am seeing ~16us wake times. AttachInterrupt takes something like 39us at 1mhz to get to your code in active mode. If you run at 5mhz and sleep except when you are playing a tone or outputting you would cut the interrupt latency by more than the startup time and use vastly less power. But really I think you could get away with hundreds of microseconds without it being perceptible.

The sleep-wake time can be minimized if you leave OSC20M running in standby but that costs 130ua (drain CR1616 in 29 days with just that) even the slow startup is probably fast enough and tbh if you are set on a CR1616 I wouldn't leave an oscillator running.

I would suggest considering a CR2032 if you can get away with it. They are cheap and around 235mAh. You still need to sleep.

Also running off these, make sure you have at least a 4.7uf cap on the board + the 0.1 on the power pin. Especially towards the latter part of their life these cells have reasonably high internal resistance.

[ObviousInRetrospect]

(I have something that I wrote that wakes from sleep at 16hz to take measurements. It uses about 1/4 as much power at 5mhz sleeping in between readings as it did running at 1mhz without sleep. "Constant" human interaction is usually well under 1/1000 active time when the user is touching it - how many seconds between touches?).

Read the low power guide. Make sure the ADC, references, basically everything is off before sleeping. If you use the BOD use sampled mode (1.2uA)

[kinesphere]

Thank you so much for all your observations and suggestions! This project is the 2nd iteration of a commercial device I sell through my company (a microbusiness, nothing fancy). I don't want to disclose all details here, but basically, users will normally use the device for a maximum of 2 hours per week. The first iteration ran with an ATtiny85 at 1MHz triggering sleep mode only if the device was left without any activity for 5 minutes. If the device wasn't much used, normally the battery would last weeks. The CR1616 is the best battery that fits in the device, which is on a very small PCB. The CR2032 is not a possibility. This new update was needed because of the chip crisis, as we no longer could get the 85 the 1616 became an option, which also allowed some other improvements (and more space on the board as we use the 20-VQFN package).

It's great to know the wake times, I didn't realise before it was under microseconds (I should have looked at 36.5 on the datasheet). I will try to implement the sleep mode on and off through operation and see how it goes (I'm working on this on Wednesday only). The board has a 0.1uF near the chip, definitely needed, but no 4.7uF. Do you think it matters that much because of this battery? I normally have 4.7uF near MCU chips as a standard practice, but as the board is very small I didn't think it would be necessary.

I will read more about the low power implementations as you suggest. I haven't explored the sleep mode as much as I should yet, I will study more now. Thanks!

[ObviousInRetrospect]

Not sure where I got 90mAh, looks like 50-60 is typical. CR1632's are ~130mAh and should be the same PCB area. Also my numbers above are probably attiny-2 series (1626) but the 1-series may be comparable. The 2-series has had better availability lately (ymmv).

Need for a 4.7uF (realistically 1 or 2.2 might be enough, although 4.7s come in 0402/X5R) depends on your peak instantaneous current draw. Which partially depends on your sensor and partially on your firmware. If you drain a CR1616 to 10-20% capacity and stick a scope on the power rail you can determine how much it matters. Or put a 100-140 ohm resistor in series with the power and see what the power pin on the MCU looks like. You can always stack a 4.7 on top of your 0.1 (qty 1 for testing, its fiddly but doable) and compare.

https://data.energizer.com/pdfs/cr1616.pdf has some numbers:
after 50mAh (on a cell rated to 60) the internal resistance is 100ohm. If you draw 3mA at peak (for milliseconds) that is a 0.3V drop which costs you some capacity. I don't recall whether microchip specifies power slew rate limits. Will vary depending on which cell you use. Look at a few, take the worst, assume users will use a random replacement.

[kinesphere]

That's very helpful, thanks again. Stacking up the 4.7uF on top of the 0.1uF sounds like a good idea for a quick comparison test.