Registration Notice

Due to increased spam, forum registration must be manually approved by a moderator! Please see this post for instructions.

*

Offline Foxhood

  • 2
  • Electronics Engineer / Mad Scientist
    • View Profile
  • Netherlands
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?
« Last Edit: October 02, 2025, 10:05:16 AM by Foxhood »
Engineer by day, Mad scientist by night and Artist by weekend.
Ask me anything electronics related :3

*

Offline LukeZ

  • 1288
    • View Profile
  • France
Re: Potential OpenPanzer-DA
« Reply #1 on: October 02, 2025, 03:41:07 PM »
Hi Foxhood, you have indeed taken on an ambitious endeavour; I won't say whether it's foolish or not. ;) But as long as it's a project that gives you something satisfying to occupy your time with, then I personally think it's worthwhile for that reason alone.

Your list of changes at the beginning of your post are in most cases things I have thought of myself at one time or another, and I have nothing to add but that they are all very good propositions.

Here's a few comments on the rest:

Aux Output / Taigen Sound
It's a bit confusing that the AVR DA names some of their timers "TCB," it might avoid confusion to refer to them as "Timer/Counter B"! But once I figured that out I understood what you're talking about. I can't see anything in your proposal that would cause a problem, other than the coding changes that will be required (but you're going to have a lot of those already anyway). The code may end up being a bit cleaner in the end, since as you say all PWM outputs will end up on the same 8-bit resolution, instead of having the Aux output be its own 10-bit outlier the way it is now (there was no special reason for that in my design, it's just what I had left).

I2C
As you've gathered, the I2C work was started with the idea of using it for barrel stabilization, as well as some driving effects. Whether those features are worth the effort I guess is up to your own preferences. I would do what interests you, and leave the rest - otherwise the work becomes a burden. I think if you were to ask the community (what five people are left :) ) what they'd want in a new TCB, they'd tell you things like "integrated main motor speed controls" and "integrated sounds." You could try chasing those desires, which would entail an even more ambitious redesign, but then the odds of a new board getting produced and distributed are so low, how many would profit from it? So my recommendation is to do what you are passionate about.

I admit I have grown a bit rusty as to certain details of these communication protocols, which at one time in the distant past I had at my fingertips. So I can't say whether you'd find I2C to be any less troublesome than I did, but I suspect it's possible it may still pose some challenges. Timing is important due to the incoming radio stream and the outgoing servo signals, anything that introduces delays that affect either of those will be immediately apparent to the end user as janky and erratic behavior. Maybe the TWI functionality on this new processor would work better, but I just don't know.

You could always break-out some pins for I2C/SPI and then the ports are there for some day in the future if you want to tackle the firmware side.

IR-Out
I'm sure there was no particular reason why I put the pull-down in that location, I can't even be sure I had the good excuse of layout constraints (but yeah, let's assume that's what it was :D). It would be better practice to put it right at the MOSFET gate, so feel free to correct that!

Smoke
I agree that having dedicated heater/fan outputs is now something that would be very good, since that has become the default arrangement in the years since the TCB was first designed. I also agree that it would be fine to leave the heater output at VBat, and I doubt even Heng Long's heating elements are going to really be affected by a slightly higher voltage, it's just a wire that gets hot. But also OP Config allows the user to adjust the heat level so if it's an issue, they can just be set to something less than 100%.

As for the fan, if 6 volts has indeed become a sort of convention, then no doubt it would be ideal if it could be powered at 6 volts. Of course it's a tradeoff with extra components and board space. I'm sure the blower motors draw very little current so if you were powering that alone the 6v regulator could be very modest, probably just an LDO especially as the input and output voltage differences are going to be so small. If you decide to add servos and turret motors to the 6v rail (which is a completely reasonable idea), that could require something more substantial. If you end up needing a second SMPS and coils and all the rest, it might not be worth it to power those other actuators from 6 volts, since in the end, the servos and turret motors don't really need it.

It's been a few years since I looked at the current smoker market situation, but I seem to recall seeing them sold both in 6 and 7.4 volt versions. You will know better than me, but if they are equally as common, I suppose you could consider adding a jumper so the user could select between 6 volts (or 5 volts if you decide against a second voltage source), and VBat for the blower motor.



Anyway, these are just some thoughts, but I hope you will take your project in the direction that both pleases you best and makes the most sense to yourself.

Finally, I see you are located in the Netherlands. It could be you're just a Brit who got blown a bit eastwards, but if you really are Dutch, I absolutely have to congratulate you on your excellent (or flawless) English. Truly, bravo.
NO SUPPORT THROUGH PM - Read why
Need a forum account? Read here
Open Panzer FAQs

*

Offline Foxhood

  • 2
  • Electronics Engineer / Mad Scientist
    • View Profile
  • Netherlands
Re: Potential OpenPanzer-DA
« Reply #2 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!
« Last Edit: October 05, 2025, 02:18:22 PM by Foxhood »
Engineer by day, Mad scientist by night and Artist by weekend.
Ask me anything electronics related :3

*

Offline LukeZ

  • 1288
    • View Profile
  • France
Re: Potential OpenPanzer-DA
« Reply #3 on: October 06, 2025, 12:44:33 PM »
Well it will be a pleasure to see what a real engineer can make of this board, and I look forward to learning about some new components and better procedures from observing your progress. I had no formal training, and was limited to what I could find on the internet and by my ability to understand what I read. If you encounter any design elements that seem bizarre, you can be sure that was due to my ignorance and not because there was a secret and clever reason for it.

All your propositions seem very reasonable to me. "One rabbit hole at a time" is a good motto. The point is to have fun, and what you have proposed already will be a considerable undertaking. I will be following with interest.
NO SUPPORT THROUGH PM - Read why
Need a forum account? Read here
Open Panzer FAQs

 

bomber-explosion