This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - Foxhood
Pages: [1]
1
« on: February 04, 2026, 02:51:24 PM »
If I recall correctly I think 8-bit sound at 22Khz is what Benedini used, and I agree that is more than adequate. We are far more constrained in terms of quality to the condition of the original recordings themselves, the relatively tiny size of the speakers that can be used in a model, poor accoustics, etc...
Not just benedini. Pretty much everyone used that setup. Clark, Elmod, Taigen, Heng Long, games like War Thunder. 8-bit, 22Khz accross the board. Only Open Panzer works with 16-bit. Which I can tell is mostly cause the Audio Library is rather particular about that. Like it only accepts 16-bit, 44khz for Wav files, though is a smidge more flexible with Raw and from Flash... Ofcourse just copying what others do is bad engineering. So i also did some of my own digging into the sounds. The Frequency Spectrum of RC sound-effects is dominated by low-frequency high-amplitude rumbling and booms, Mid-frequency mid-amplitude clangs and hisses and quite a bit of Hard-Clipping when it comes to explosions. The audible frequencies are well below the Nyquist Frequency if using 22Khz sampling (though 11Khz would be too low), while the lack of low-amplitude high-frequency audio renders no tangible benefit to using 16-bit, Not helping either is that unless you use a high quality Audio DAC you will only get an effective resolution of about 1 bit less than the DAC on chip (9-bit for AVR-Dx, 11 bit for teensy3). From this the conclusion is that yeah: 8-bit, 22Khz is definitely the sweet-spot for this kind of stuff. Though the presence of Hard-clipping (which results in harsh-sound high-frequency odd harmonics) and the use of a on-chip DAC peripheral (processor noise) does render the use of a Low-Pass filter as probably being a good thing. ...Can you tell that I also dabble in Audio Electronics? 
2
« on: January 31, 2026, 05:33:06 PM »
Milestone reached!
After hours of non-stop cacophony and trying out every single Filesystem combination possible in order to solve a specific annoying stutter (SD Cards, SdFat and filesystems be fickle).
I have successfully gotten 6 sound channels operational, mixing and getting output on a dinky speaker in good quality!! Along with repetition when needed and quick Fade-in/out. All with just the SD Card, an AVR64DD32 Microcontroller IC and a random Output Amplifier i had lying around.
This means that It looks like this crazy idea of mine is actually going to work! And possibly just as well as the original OPSC.
Now that i know that. I can start turning this from experimental to a full solution in both software (all that logic) and hardware. This is probably going to take a while though so don't hold your breath just yet.
On the Audio file specs. These are the parameters I'm currently working with and almost certainly will stick to:
=Sample-rate: 22Khz
=Bit-rate: 8-bit Signed PCM
=Channels: MONO
=Format: RAW (Header-Less)
This makes it so the processor can just grab data and immediately start multiplying based on volume and adding it in. Not as high in sample and bit rates as the original OPSC, but for mechanical sounds there is no real difference in quality honestly.
3
« on: January 17, 2026, 04:46:03 PM »
Unfortunately the OP Sound Card code is not directly portable to any other processor than the discontinued Teensy 3.x devices, which had very specific sound capabilities that made them unique, and which my project was developed around. To recreate the sound card on different hardware will require not only a new board but a complete rewrite of the firmware based on a completely different approach.
This is not something I'm going to undertake, but user Foxhood recently started a thread about his project which he calls OPSC Lite, which you should follow.
I would note that the code is like 98% compatible with the newer Teensy 4.x as though the main website doesn't indicate as such: the sound library has been ported over cleanly to the new processor, restoring all functionality except for the on-chip DAC as the T4 lacks one. Porting would mostly be a matter of a little bit of rewiring (SD from SPI to SDIO), adding a simple little I2S DAC (e.g. SGTL5000) to the board and a few relatively tiny tweaks to the code like swapping the Audio DAC output block with I2S Output and replacing the old SdFat fork with the regular version. I investigated this possibility as part of my dive into potential solutions to the audio dilemma. Honestly would have gone for this approach if my experiments didn't show a very interesting possibility in a spiritual successor to Benedini's work with AVR. Still. I'm keeping this in mind as a back-up should my efforts fail to pan out. After all. We do need a solution
4
« on: January 07, 2026, 08:48:05 AM »
Hello. Was a bit absent during december. Know how it goes. Lots of things to do, and good luck getting any packages around the holidays on time... Progress was slowed down a bit because of it. But i'm back at it. Hello, I’m not a developer and I don’t really understand what you’re doing there, but it sounds very exciting. I think many people would love to have a kind of TCB sound board again (similar to the Teensy 3.2). It’s especially cool if you can define all the sounds yourself using a micro SD card.
and if its going to be cheap ( becouse i think thats what the most people need, good and cheap) than thats gonna be the perfect solution for everybody.
best regards Ilias
The gist is that i'm trying to create something akin to the Benedini TBS in size and components, but with the same kind of functionality as the Teensy 3.2 OPSC and cheap enough in material that you could like get a bunch made at PCBway or something through the inclusion of compliant BOM and Centroid files. Or hell. Maybe some chinese copycat starts manufacturing for even cheaper! For the sake of the Open Panzer project as a whole I'd consider that a good thing. Wouldn't mind recognition and a tip though if for some reason people do start building my offshoots ;P. Agreed whole heartedly, I need a few sound cards not just one so something compact, powerful, and flexible is long over due..
I'll do my best. Are you looking for sound from RC inputs or OpenPanzer specifically? Cause latter is the priority at first. Former i don't have much information on what people are looking for, like channel count. I'm trying to keep things in the realm of being possible to build oneself using a miniature reflow plate (e.g. Sequre T55 or Miniware MHP50) and compliant with assembly services. and if its going to be cheap ( becouse i think thats what the most people need, good and cheap) than thats gonna be the perfect solution for everybody.
That's wishful thinking.
Look what happened to the Benedini sound modules.
Chinese copies caused Benedini to give up, the software is no longer being developed.
You can still get these copies for very little money...
That is kind of why I'm taking a stab at this. The only option atm for programmable sound are copycats making clone boards that are quite frank: horribly outdated and reliant on old pirated copies of what is now essentially Abandonware. An Open-source alternative is much needed. On costs: I'm avoiding stuff like double-sided components and overall complexity to push assembly costs down as much as possible. As stated above: Intent is for it to be feasible to get it however one wishes.
5
« 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...
6
« on: October 03, 2025, 03:34:53 PM »
One of the things I've been wanting to do for a while, is to get involved with Open-Source projects proper and put my engineering degree to use. I also got this certain cheese-wedge shaped Tank-Destroyer at a very low price that I want to make my own. So this is a bit of a two birds, one stone. And yeah. I do very much enjoy figuring things out and puzzling PCB layouts.
Honestly I got a way easier task at hand than the v1 likely was for you. The ATMega2560 is kind of infamous for giving PCB-designers nightmares. The allocation of pins to peripherals is all over the place, leading to downright cursed routing if you want to make the most out of its peripherals. Judging from the V1: I guess you experienced this first-hand. Compare that to modern microcontrollers where you get increasingly more flexible Port Multiplexers and it is Night vs Day. I also benefit from FET based drivers and Step-Down converter efficiency reducing the need for thermal design.
Result: I don't have to do weird routing like how you had to stitch the Timer2 IR output by going up to a resistor and then down, nor do I have to care about giving components like the Linear Regulator and motor drivers a lot of copper to dump heat into.
Though I do have to deal with some extra components and some EMC considerations like integrating Ferrite Chokes to keep switching noise from getting in/out.
I2C:
You are correct: if i can make the space in regards of free pins i might as well include a JST-SH with Stemma-QT compliant pinout. Worst case scenario: I declare the tiny footprint as DNP.
Smoke/power:
You have a point. The air-pumps are small 6V motors that have been listed as consuming up to 600mA, so they are not too power-hungry. LDO is an option, but I also have a tiny 1A step-down circuit that uses a LMR54410 that might prove a better solution. We have come to a point that a LDO like the MIC29300 can be bigger and more expensive than a Step-down circuit.
ESC:
I'm just gonna let that remain its own thing. As neat as it may be to have it all integrated. It would greatly complicate the programming and deny flexibility. You end up with something like the Clarks. Having to create different designs for different strengths. Stuff like that Scout ESC-Mini NielsD is working on is far more interesting to have.
Sound:
I have mulled over this. Mostly cause there may be a bit of a problem that with the death of both the OP-Soundcard and the Benedini series. The only practical solution is to use a Taigen sound box.
Easiest solution would be to simply update the OP-Soundcard to have an I2S DAC on-board. Which would make it possible to use a Teensy4.0 instead.
In the long run something more purpose-built could be done. You don't really need that much for sound. Just gotta be able to retrieve and mix two blocks of PCM data and output them to a DAC. A task even an AVR chip can do if you give it access to speedy memory. The new ones even have a 10-bit DAC output that could simplify things further. So something that can do similar to the Benedini is possible. Just need a way to get different blocks of PCM data in as fast as possible. Might do some experiments with Flash memory and SD to test the limits. If there is enough processing power available on the main chip, it itself could potentially output sound, though that might be stretching it a bit and add a lot more work in coding...
BUT one rabbit hole at a time... for now I'm just gonna prioritize the TCB and at first probably make due with a Taigen box. Sound experiments and TWI will be on the side when I need to wait or take a break from the hardware side.
PS: My parents hated dutch children's television with a burning passion. So I grew up with british television instead. Result: I've been mistaken for a Brit quite often!
7
« 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?
Pages: [1]
|
Show Posts