What kind of “higher spec speakers” are you talking about? Have you seen >3W 50-20000Hz dynamic range bass speakers in 22-28mm diameter? Personally I haven’t seen any better speakers than we are using now with current sound boards.
1 Like
Regarding the USB-C port on the board: don’t do that, because as Fredrik already said - it takes much more space on the board. What we have now on the V3 Proffieboard is the ideal design I think: onboard micro-USB port + pads for external port wires, so if you want to use the USB-C port you just solder an external one to the board and you can desolder the onboard micro one.
1 Like
That is a good point but I have been playing with some slightly larger speakers (28 - 40mm) and they have some interesting results. Most though have a coil that will take 5 -10w rms so they are not being driven very hard.
I always think its a bit of a gimik having a speaker that can produce a range up to 20khz as most adults can only hear upto about 14khz and even children will struggle above 18khz. But hey ho, that’s just how the cookie crumbles.
For sizes of 28mm and smaller you are correct. They have been well designed indeed to produce the best possible sound from such a small speaker.
Having worked with a dual microcontroller setup in the past, this seems fairly viable to me. In particular, from the schematic of the 2.2 anyway, the fet driver pins in particular could be replaced with an I2C/SPI connection to another much cheaper micro (or even various sizes in various versions, tbh) that would be free to use all timer resources for PWM driving. My specific chip knowledge is terribly out of date to give suggestions (I worked with mostly 8 bit PIC micros, and some of the generic Arduino chips), but it should work out pretty well if you can get the space on the pcb for it.
Indeed, using i2c would be particularly nice, because it uses no extra pins.
Although, I’ll need some way to upload new programs to the external processor of course. Finding space might not be too bad as long as the external processor is small enough. In fact, it could even save space if it simplifies the routing enough. An 8-bit PIC would be fine, as long as it comes in a small enough package…
Very little in the way of stock for 8-bit PICs and AVR chips too, but basically came up with this:
With various 8 pin PICs, you could probably have 3 channels of PWM and the I2C connection. Bump to 14 pin package, and it would be 4 or 6 PWM channels (depending on painfulness of combining standalone PWM with CCP) and I2C.
With AVR chips, Probably the same 3 PWM + I2C for 8 pin chips, but depending on how their timer modules actually work (I don’t currently have significant AVR datasheet skills), you might be able to get 6 channels PWM + I2C in a 14 pin package.
There are larger chip options, particularly AVRs seem to actually scale up PWM outputs, according to their feature charts anyway, 16 ports on a 32 pin chip. Larger pin count PICs don’t have significantly more PWM ports. (though you could bit-bang pretty easily with timer interrupts too, depending on how high the frequency needs to be).
Re-programmability on board is technically plausible with an external usb-serial for the 14 pin chips, much more janky for the 8 pin chips. I would posit that if using one of these as a super low cost option just for offloading PWM (And possibly analog or digital input) as a peripheral multiplexer more than anything else, then it might not be necessary to re-program once a suitable control program is built.
I’m really just spitballing here
All 6 PWM on the board have to be synchronized though, otherwise you can’t join them together to drive more powerful LEDs. Driving some PWM off one chip and some PWM off another is not ideal.
(Please take w/ a grain a salt; I’m just getting into the hardware side of things)
That said, availability seems to be the killer feature right now. For example, the teensy 3.x are OOS:
We’re hoping to make more Teensy 3.6 by July-August time frame, but even when we do, we’re not expecting to have enough chips to fully meet demand until 2023
And a while back RPI put out some really interesting facts about RP2040 availability which gives me a lot of hope (Raspberry Pi Direct: buy RP2040 in bulk from just $0.70 - Raspberry Pi)
We have sufficient wafer stock on hand to produce 20 million chips, with more on the way. If you want to build your product on a microcontroller you can actually buy in 2022, RP2040 is your friend.
Even as a complete newbie, the “Hardware design with RP2040” PDF is incredibly interesting & teaching-oriented. They even give a complete example of a SD card, I2S, and I2C companion board. It even looks like others have made example libraries to use PIO for WS2812 & I2S.
ESP doesn’t look bad either; it has a ton of peripherals, and availability seems really good.
Selfishly, I just want a proffieboard to be available & affordable now. So another board, available now, cheap, software compatible, and lacking some of the extra pins & features… yes please! Maybe a bit more like Raspberry’s model… some models with all the features, but then the RPI Zero with way less. A proffieboard and a proffieboard-lite. CPU, motion, sound, SD, neopixel, battery, and a couple buttons.
And while it’s completely over my head, I’ve been playing around with easyeda and the RP2040 tutorial to rebuild their circuits. I’m sure it’ll go no where, but it’s giving me more appreciation for the work that goes into this 
1 Like
Currently I’m breadboarding stuff with micromod.
Since Teensy4 is mostly working already. I’m trying that first, and then I’m going to try other CPUs to see what I can get working. Right now I’m having an SD card problem, and I’m not sure if it’s a hardware or a software issue.
One problem with the RP2040 is that it doesn’t have quite enough pads to control all the stuff a proffieboard is supposed to do. I’ve been racking my brains trying to come up with ways to use less pads, but so far I haven’t had much success.
… aaaand now I know it’s a software issue.
1 Like
It should probably go in a separate thread, but when I was having problems with the SD card on the teensy I had to lower my clock speed. Probably because I’m using the breadboard, but I ended up having to manually change SD.cpp to lower the SPI speed (hardcoded to 25MHZ, but I lowered mine to 15MHZ).
I can’t remember if that was on the teensy 3.x or 4.x, I have both I’ve been playing with. Should we start a teensy 4.x debug thread?
1 Like
I don’t think that’s my problem, because I tried it with a Teensy 4.1 which has the SD card onboard and I’m getting the same issue.
Next thing to figure out is if it is because the Teensy libraries have been updated to use a recent version of the SDFAT library, or if it’s an SDIO vs. SPI issue.
1 Like
Time to read blocks: Average speed: 21271.10 kb/s, 241.17 simultaneous audio streams.
Wat?
lol whuuuuuuut??
1 Like
I’m experimenting with a Teensy 4.1, and the SD card reader that is on it is apparently very fast… Also, the processor runs at 600Mhz, which helps.
Dear Master Proffie, please bring us larger reset and boot buttons on the board. May the force be with you.
Love! Can I transplant some switches instead the little button pads?
That’s what I did. Out of this kit.
Of course you could also remote some other switches by tacking wires to the pads instead 
. Reset already has an actual pad next to GND. Boot would need to attach where the button currently is.
If you need to use the buttons often, you’re doing it wrong.
3 Likes