Welcome back to the factory. We've got some production updates to share with you and a few PiicoDev prototypes on the bake.

First up, some production news. Last week, we started our assembly of our PiicoDev RGB LED module. This is the first of our line of what we're calling internally smart modules, just because there's a microcontroller on board. The job of the microcontroller is to translate the I2C signals coming in to whatever happens to be on the board. In this case, we've got three GlowBits, so you can control three GlowBit LEDs from an I2C connection over with the PiicoDev libraries.

The reason I mentioned smart module is because our first prototype for the day is the PiicoDev microSD card module, and you'll notice this has a pretty similar topology. We have the microcontroller in the bottom right and a little address selection switch in the bottom left. So we've been able to template that design for the RGB module and reuse it for this microSD module.

The point here is PiicoDev makes it really easy to read from a bunch of sensors, but so far, what if you want to do some kind of data logging project? It makes a lot of sense if you can have a device on the same bus that you can just send log commands to, so log this variable.

Jumping into the schematic, the schematic for this one is really simple. It's really just the microcontroller interfaced with a microSD card. A lot of the development for this project is going to go into the firmware to make it really easy to use in MicroPython using the unified libraries. Quite simply, you've got the microcontroller, in this case the AtTiny1616, and it is just connected over SPI to a microSD card. We'veGot a nice big 10 mic capacitor because SD cards can be pretty hungry when you start pushing data to them. Otherwise, it's just quality of life stuff.

We have a power LED that will default to on always, and it will actually be user controllable. A little while ago, we had this discussion about the RGB module and whether to make the power LED a true power LED or to make it user controllable. I actually did a backflip on that choice. On this board, because it's an LED board, I decided to make it user controllable but always default to on. When you plug it in and it powers up, you've got power, but you can always choose to turn it off if you want to. Because after all, this is a display board, it's kind of unusual to have this glowing green LED constantly on while you're doing some colourful patterns or displays.

Anyway, I've digressed enough. I've used that same circuit for the microSD module. So we've got the user controllable power LED and a few hardware address jumpers so that you've got 16 options on the board. But of course, you'll always be able to change the address with I2C commands. So you'll be able to update the address to anything you like.

Enough getting in the weeds with the schematic though. The story of this board is really that about design optimisation or design for manufacture. We've already got the Makerverse microSD module and so necessarily we've already got a microSD connector. The thing is, this connector is actually far too wide to fit on the PiicoDev board between the connectors. If we were going to use this connector that we already have, we would have to put it on the back side of the board. And that's a really big deal. I really didn't want to make the PiicoDev microSD module a double-sided load. The moment you go to double-sided load, everything gets a lot harder. You've got like custom fixturing in the paste machine because you've got to be able to support a board that already has components on the underside. So you've got to somehow support that board without fouling those components. Really didn't want to go down that path.

And so after a bit of digging around, I found a much narrower microSD socket. This one isn't sprung loaded. It's just a push-in pull-out, but it is about as small as you could possibly hope for. And so by taking on this new part, we've avoided having to do a double-sided load on this design, which is, I think, a huge deal.

Something that I find quite satisfying is this just comes nice and flush with the edge of the board. If you look between the SD socket and the PiicoDev connector, there's those decoupling caps just kind of nestled in that cutout. That's pretty neat.

And still on the topic of smart modules, the last prototype I have for you today is the PiicoDev buzzer prototype. This one, the prototype's been submitted. It's in the mail, and it looks pretty familiar to the other smart modules because, again, we've got a microcontroller, we've got some address jumpers, and then we've got the device in question.

So I think these smart modules are going to be really useful for PiicoDev output devices. It's really easy to just find off-the-shelf I2C sensors like light sensors, weather, or what else, distance, etc. Those are all really low-hanging fruit because they're just I2C devices. But for output stuff like buzzers and lights,We're really going to have to use smart modules for that, I think, because a buzzer clearly isn't I2C compatible. And so functionality for this that we have earmarked is pretty maker staple stuff, things that people are used to, say, in the Arduino environment, like generating tones at a specific frequency for a given duration. And then maybe you can play a melody with that.

Now, if you've ever tried to play a melody on a piezo transducer, you might have noticed that as you go up that scale, as you get to higher and higher notes, things start to change quite a bit. There's like extra harmonics. It gets quite a bit louder and squeakier, which can be quite, you know, off-putting. It kind of ruins that melody effect.

So just naively driving a piezo transducer with a square wave, you can create tones that are suitable for like indicator tones or whatever. That's fine. But actually having notes in a melody, it can become, ah, it's not great. That has to do with a couple of things. The response of the buzzer, the frequency response, and also, I assume, the perceived loudness of different tones.

Here's the frequency response for the buzzer that I'm looking at. And it is, it is respectively flat below about, you know, one and a half kilohertz, which is about that kind of pleasant tone range anyway. Anything above a kilohertz or two and things start to get a little shrill. So this is like, this is quite flat. What do we have? We have a sweep of, I don't know, like maybe like six to eight dB.

Even so, it's probably still appropriate to include some kind of volume control because buzzers can get pretty annoying if they're just going constantly and you can't really, change that. Now you might be tempted to volume control the piezo using PWM. Tried it out. Doesn't really work. Really, all it does is distort the sound that comes out when you move away from 50% duty cycle. In fact, let's, let's just do it. Let's just do it. Here we go.

500 Hertz, five volt peak to peak square wave with a 50% duty cycle. That's nicely annoying. That's if I take that duty cycle all the way down, this actually bottoms out at 20%. You'll hear it's about the same loudness. It just sounds kind of more scratchy, more distorted. If I take it up to 80%, it's basically the same. So there you have it. You've got, I mean from 50% down to 20% is only a three dB decrease. So it's actually, it's actually not that much, but there was definite, there was definite change in the timbre of that sound. It was definitely distortion. And so PWM, maybe, maybe not the best control strategy for volume.

So here's my proposed solution. We have three separate PWM pins and we can choose whether we have a clean signal or an attenuated signal through some selected resistor. And I will select these later, once I get the buzzes in and I can have a look at that perceived loudness.

There is also a bit of a, a bit of a bridged way that you can drive piezos. So this would be by replacing that ground leg with another GPIO. So by driving it with a bit of a push-pull arrangement, you could go one louder with this.

Ideally, we'd sked around all of this and just use the DAC that's in the Attiny 806. Taking a look at the DAC specs though, we can see it's only good for about a milliamp and for a capacitive load of 30 pF. I think the buzzer that I'mGetting has about a 20,000 pF load. So clearly this isn't going to work out. Of course, you could punch it through a buffer of some kind, but now we're getting a little bit more complicated. If I can jag it just by selecting a couple of resistors that we may already have, then we'll stick to that.

Overall, usually makers' experiences with buzzers is that you don't really have volume control unless you bring in a potentiometer. So there you have it, a bunch of development on the next PiicoDev smart modules. I'd love to hear your thoughts about this volume control strategy, whether you feel it's appropriate or whether you can think of a better way to do it with simple parts. Let me know on the Core Electronics forums.

Until next time, thanks for watching.