1

Open Source Sound Dev / OPSC Lite

« on: December 01, 2025, 04:21:17 PM »

Took a detour from my TCB iterating efforts to experiment with sound involving one of the smaller AVR-Dx (AVR64DD28) and its built-in 10-bit DAC.

My reasoning is that if the original OPSC was a 72Mhz ARM processor juggling "6" channels of stereo, 16-bit, 44Khz PCM data from a uSD card via a SPI bus. Surely a 24Mhz AVR processor could juggle a few 8-bit mono channels. Benedini showed it was possible for AVR to do sound and that was with a older memory constrained ATmega8 type connected to slow Flash memory, no DAC and long before libraries like sdFat became the optimized beasts we know today. Only thing the AVR lacks is a DSP for floating point math so one has to cheat a little to keep mixing data within the ballpark of the ALU by using bit-shifts and multiplications for manipulating volume.

Approach is fairly simple. Two output buffers with one marked as active. A timer routine slowly goes through the active buffer pushing the values to the DAC output while the processor is prepping the other buffer. Grabbing pages of 8-bit signed 22Khz PCM via sdFat from files, manipulating volume and adding them to the buffer being worked on. Been running through benchmarks with pages of 1024 bytes and i've managed to get it to handle 9 files before it started to fail at preparing before the DAC Timer caught up to it. Which is very promising considering the old benedini only managed 2 channels and the OPSC could do 6. Honestly would have been happy with just 4 really. The main reason I'm getting this far is because this little AVR has 8KB of RAM which lets the sdFat library spend far less time seeking as it would with older ATMega.

Next is to get Logic running and test with actual soundsets rather than little test-waveform files, oh and see if i can optimize the SPI driver as currently it is using the default on within the core. Since I'm working with raw-files without a sound library i got a lot of freedom in how i deal with data. Can even do stuff like pre-processing files to make playback easy (e.g. behead them so you get RAW) and simply check the available variable to know when the last few pages are up for fading. Gonna take a lot of coding. But the progress thus far is fairly exciting.

I've also drafted a small board for it with the minimum components to see how small it actually is. It is really just the AVR, a generic LDO, uSD Slot and the MAX9768 (same as regular OPSC). BOM puts it at like 10$ plus PCB which makes it the cheapest sound-card yet, may be good for existing boards, though i am definitely looking at fitting the circuit unto my TCB Re-design as a co-processor. Perhaps even see if i can put it in charge of some 32A drivers...

2

TCB Dev / Potential OpenPanzer-DA

« on: October 01, 2025, 09:57:02 AM »

I’ve taken on the ambitious and potentially foolish endeavour on giving the TCB a re-design in hopes of creating a board that is a bit more future-proof. Lot of stuff on it has aged over the past decades with all three of the main ICs being overdue for substitution as their prices increase well beyond being worth the cost.

The biggest change I hope to accomplish is to replace the ATMega2560 by one of its modern counterparts: The AVR128DA64. Hence the working-title of “OpenPanzer-DA”.

The DA isn’t as big as the 2560, but it is very flexible. Featuring modern sensibilities like Port Multiplexing for most (now smarter) peripherals, Timers to spare and a fully functional Arduino Core. I’ve checked everything incl IO, flash, eeprom, usarts and timers and I believe OpenPanzer can be made to work on this without any major obstacles. With a few perks to be gained like a <24Mhz internal oscillator, programming from USB-Serial bridge via SerialUPDI and vastly easier routing.

Besides that some other changes I’m working on:

    • Replace FT232 by CH340C
        ◦ Add switch to switch from Serial to 'Recovery-Mode' (programmer)
        ◦ While I’m at it. Replace Micro-USB with USB-C
    • Replace the BJT L298P by newer FET based bridge(s) (currently checking DRV8874)
    • Probably remove the mostly unused LCD Header
    • Simplify some smaller bits (e.g. Replace BC848+2 resistors by single 74LVC1G06 Open-Drain Inverter, use Resistor-Networks more often)
    • Add dedicated Fan/Blower output due to increased prevalence of this type kind of smoke setup in newer models
    • Replace Schottky with PFET Polarity Protection.
    • Implement SMPS (Currently designing around TPS65208)
    • Use KiCad as Eagle is facing obsolescence next year.
        ◦ Will try to include (meta-)data for PCB Assembly services (JLCPCB / PCBWAY)
    • Give all RC/Servo Channels current limiting resistors..

Let me know if there are any thoughts on these kinds of changes. Or if anyone got any suggestions/wishes.

So far overall layout is coming along nicely, but there are a couple things i'm looking for input on before i route myself into a corner:
AUX PINS:
The AVR DA has a different timer setup. It gives you two big 3x-16b/6x-8b channel timers (TCA), An asynchoronous waveform generating beast (TCD) and five single-channel utility timers (TCB). Most OP/Arduino functions can be mapped to these in almost 1:1 fashion except for the AUX/Taigen timer as I lack a 3rd TCA for it. Best solution for that one is to move the Taigen sound duty to a dedicated TCB and hand the AUX channels over to the same timer in charge of motors and smoker (TCA). Consequence is that the AUX channels go from being their own 10-bit thing with a lower-frequency. To being the same as the motors: 8-bit and speedy. Besides that still got the analog and digital functions needed.

Are there situations where this might be a problem? Or is this perhaps a perk?
I2C:
Was hoping to maybe learn a little more on where things went awry with implementing I2C without Wire's habit to occupy the processor till a complete transaction occurred. The TWI Peripheral has seen some changes to make it smart enough to perform actions like I2C addressing and responding with ACK without user interference, so it may be less of a nightmare to implement if the issue is related to too much babysitting. Is there still interest in getting I2C working?
That way I know whether to invest effort on trying to figure it out.

Alternatively I could see about creating a Bus specifically for the newer BNO085 that uses SPI. I find that SPI is vastly more reliable than I2C in most circumstances.
IR-OUT:
I’ve Noticed that the control FET for IR out has the pull-down before the limiting resistor, rather than after. Any particular reason as to why? Or just layout constraints?
SMOKE:
Smoke units have mutated over time and not in a fun way. Not only are there seperate blowers everywhere, but most of them are made with 6V air-pumps and Heng Long apparantly decided to have their own heater also be at 6V starting with the TK6.0S. OpenPanzer can’t work optimally with the blowers at 5V (reduced power) and might overheat some heaters with constant 7.2V. The air-pump blowers seem to have become pretty popular as they are surprising effective.

I'm trying to figure out a good solution for these newer setups as the current approach of attaching a 5V fan to a AUX channel isn't ideal anymore due to their increased prevalence in newer models. At the very least I’m going to give them their own output on the board so the AUX pins remain available for other purposes. But their voltage is still a nuisance.

I could create a seperate 6V rail dedicated to Actuators (Servo, Fan, Optionally the motors). Accept slightly below maximum performance by sticking to 5V for the blower, or use 7.2V and use PWM to keep things from overheating. Heater seems best to keep at 7.2V as that is most widely accepted by most aftermarket smoke units with only Heng Long's own being sticks in the mud.
 
Any thoughts?