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 - LukeZ
1
« on: November 25, 2025, 01:27:38 PM »
Hi Ilias, thank you for the kind words about the project, I appreciate it and I'm glad you like it.
It's true that there is a lot to learn, especially if you are going to try to create your own board. But it can also be rewarding and gratifying to assemble something yourself, and if you like what we call "tinkering" in English then you certainly have many hours of fun ahead of you (and probably a few hours of frustration!)
But do let us know if you build a FatFingers shield, I'm sure others would be interested to hear your insights about the process.
2
« on: November 24, 2025, 03:01:30 PM »
If you want to assemble something and have all the same functions as the original TCB, the FatFingers shield is your best option. The Baldock shield is missing certain capabilities, including IR.
None of the shields will include sound (the Heclo shield because the Teensy 3.2 is no longer available, and the other shields because they are using the same design as the TCB). However all three shields will still let you use Taigen sound cards, or the Benedini/DasMikro sound cards.
The Heclo shield has onboard motor drivers. The FatFingers and Baldock shields will require ESCs.
3
« on: November 24, 2025, 08:10:23 AM »
Hi Ilias, Yes, it is very unfortunate the Teensy 3.2 was discontinued. Unfortunately, the replacement versions that are now sold (Teensy 4.0 for example) are very different and it is not possible to simply move the firmware from the old chip to the new chip, in fact the firmware needs to changed and we need a completely different approach to creating sound. Maybe some day someone will make these changes, but it is a big undertaking, and for now we must consider the Open Panzer sound project to be at an end. The Taigen sound cards are the best alternative if the goal is to keep the cost as low as possible. Their sound is not great, but they are very inexpensive, and they can be connected directly to an Arduino Mega. In answer to your question about the Heclo Shield, yes it does include motor drivers, so no additional ESCs are necessary. At the same time, it is good to remember that ESCs can be purchased for very little money from the Chinese sellers. I think you could probably purchase 4 ESCs (two for the drive motor, and two for the turret rotation/elevation) for probably 50€. Finally, in regards to the Scout ESC that you have - you do not need to use an FTDI cable with them, nor will they transmit any information in Snoop. All you need to do is connect the Scout to the TCB with a serial cable as shown in the Wiki here. You do not need to worry about the baud rate - when the TCB communicates with the Scout it will manage that automatically.
4
« on: November 22, 2025, 08:08:57 AM »
Hi Ilias, I'm glad you are liking the Open Panzer controller, and you were indeed very fortunate to get a sound card since those were never manufactured. Your assumption about an Arduino Mega + Heclo Shield is correct, EXCEPT, that the Teensy 3.2 processor which is needed for sound, was discontinued by the manufacturer a couple years ago, and is no longer available. So PCBWay would not be able to obtain it, and although the Heclo shield would still work, you would have no sound (the Heclo shield combines the TCB and the Sound Card onto a single board). The two other shield designs (FatFingers and Baldock) also let you create a TCB with an Arduino Mega. The FatFingers shield basically recreates all the functionality of the TCB, the Baldock has fewer functions. Like the original TCB, neither includes sound or speed controls. However, by the time you purchase these boards you will probably have spent just as much money as it would cost to simply buy the TCB from Torro. Depending on what you want to control, you can also use an Arduino Mega all by itself but with limited functionality. By connecting an ibus or PPM receiver, and some RC speed controls directly to the Mega, you can drive your tank and control the turret. Some have even added lights and recoil servo directly to the Mega. But if you want to use the smoker, or IR, or airsoft and some other things, then it becomes necessary to add other components through a shield or your own custom board, and the Mega by itself is no longer enough. This is the thread where all discussion about using a Mega as a TCB is discussed, I'm sure you have already found it: TCB Firmware with Stock Arduino MegaThe first post in that thread has information for using the Mega alone, but then the discussion continues for a long time on all the various shields and circuits other people have experimented with. Making your own TCB with a Mega is a fun project, but the more you want it to resemble the original TCB, the more complicated the design becomes, and eventually it makes more sense to just buy a prebuilt TCB. Luke
5
« on: October 30, 2025, 08:50:14 AM »
I spent some time last night thinking more about the current sense procedure and I probably had not understood it very well when I wrote my earlier reply. I've looked at the code, the datasheet, and my earlier notes more closely and I've concluded you are doing it correctly, and I also think that the choice of 1.5k for the Rsense resistor is still a good one for the VNH7040. This resistor determines the maximum current we can sense, and you're right, given the ratios for the VNH7040 that comes to about 14 amps. But that is plenty, even if in theory the motor driver says it can do more than that.
But none of that is what you were really commenting on, I just got sidetracked. You were mentioning the fact that sometimes the Multi Sense pin goes to saturation, indicating an error condition; but you knew you weren't drawing anything near 14 amps. I agree with you, this is not likely a real error, but rather a transient condition. I would suggest that instead of checking for a fault condition every single time through the main loop, which will detect even the briefest of transients, that instead you look at how we are measuring currents and copy that approach for checking the fault conditions. Firstly, we only measure currents at some predetermined frequency (CurrentReadFrequency_mS which we set to 100 milliseconds). And even though we read currents ten times a second, we don't throw an overcurrent error until we have 10 consecutive readings over the limit (so in total the overcurrent condition will have to last persistently for 1 second for us to consider it valid).
You can adjust the actual frequency and count of consecutive fault indicators to whatever makes the most sense in your testing, but the idea is that this lets you weed out "false positives" or temporary spikes that are not actually relevant or persistent.
6
« on: October 29, 2025, 03:05:45 PM »
Hi Neil,
Ok, I can see your GitLab project now, but only when I'm logged in. That's fine for me, but it would be good if you could set it to be visible to everyone, whether they have an account or not.
I've spent some time again beating my head against the wall with the VNH7040 datasheet. In terms of current sensing, it looks like it uses the exact same process as the VNH5019, only with different constants. What is so confusing is on page 16 of the datasheet they give the same Vsense of 0.5v for two current levels (Iout 0.05A and 0.3A), and again the same Vsense of 4v for the three remaining levels (Iout of 3A, 5A, and 10A). This should not be possible. The sense voltage (current across the sensing resistor) should change as the current changes.
Of course it would be nice if they'd tell us what resistor value they're using for their measurements, but we can deduce it. On the VNH5019, the implied resistor value was fairly consistent across all their readings, it came to about 1.1k. I can't remember now why I chose 1.5k.
But with the examples we have from the VNH7040 datasheet, if they can even be trusted, which I'm not convinced they can, the implied Rsense resistor value ranges all over the place. Of course, we can only have one value on our board (these are R115 and R116 on your schematic).
Anyway, when you're calculating 14.3A, all that means is that the voltage over the Rsense resistor has saturated - and probably, since you don't think you were drawing 14.3 amps in real life, it saturated much earlier.
I think really the best way to understand what is going on would be to take some actual measurements of current draw and simultaneously the voltage at point M1_MS (or M2_MS) on your schematic, and get some empirical evidence of what the ratios are.
A few more comments:
In your code, you might want to set motor state to MOTOR_STOPPED in these two function. Otherwise the state will still show as ROTATING even when stopped, and the current sense measurements will still occur. However I don't think this actually would cause any problems, but I thought I'd mention it anyway.
void StopMotor1(void)
{
M1_Speed = 0;
M1_OCR = 0;
if (BrakeAtStop) BrakeMotor1();
else Motor1State = MOTOR_STOPPED; // ADD THIS LINE
}
void StopMotor2(void)
{
M2_Speed = 0;
M2_OCR = 0;
if (BrakeAtStop) BrakeMotor2();
else Motor2State = MOTOR_STOPPED; // ADD THIS LINE
}
Finally, I should have told you this a year and a half ago, but the reason I put ADC7 to +5v, is so that if someday a different hardware version was made, that new version could set it to Gnd, and then the firmware could read that status of that pin on boot, and adjust the code to fit the hardware. This would let us have a single firmware for both boards, instead of two. Of course there was no way you could have known that, and it's not a problem to have two distinct firmwares. But if you ever have to redesign the board for some other reason (God forbid), you could make that change.
7
« on: October 27, 2025, 09:24:24 AM »
Congrats on validating your design! I had no doubt it would work but it's nice to see it moving something in the real world. Congratulations also on sticking to the project over the long term. It's easy to start a project; hard to finish.
The tallest 10x10 heatsinks that I have seen are 10mm tall (ie, it's a 10mm cube). I'm sure you've seen those. The only thing taller that appears to be close in size is 9x9x12, if you search for that on Amazon or AliExpress you'll find them easily.
Since you don't have caps in-between your two chips like I did, maybe you could use a single wide heatsink that would attach to both. I am seeing 22x8x7 and 22x13x11 on AliExpress. I don't know if 22mm is quite long enough, and you don't gain anything in height, but you would get more surface area.
I tried looking at your project on GitLab but although I can navigate to the page you linked, the code is not visible. Maybe it needs to be made public somehow, but at any rate it would be good if anyone could view it without having a GitLab account.
8
« 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.
9
« 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). I2CAs 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-OutI'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  ). It would be better practice to put it right at the MOSFET gate, so feel free to correct that! SmokeI 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.
10
« on: September 28, 2025, 04:17:01 PM »
Hi Dean, that is a sweet looking truck. It must be really gratifying to see a physical object come to being in front of your eyes, from what was only a CAD model on a computer several months ago. Now comes all the fun of bringing it to life. I will especially be looking forward to more detail on your belt-drive setup which sounded very unique and interesting.
I hope you were able to resolve your TCB problems from earlier, but let me know if anything is still amiss.
11
« on: September 28, 2025, 04:02:18 PM »
I totally understand about "the rest of life" getting in the way of hobbies. Better that than the other way around. Anyway that's a cool looking board, and most importantly, it is very small! I have to say you did a very professional job on the design, I only just today noticed a ground frame around the crystal, though it was also visible in the Altium picture you posted last year. I am going to take a wild guess and declare that this surely can not be your first PCB layout. Although I don't presently have a model to test this in, I think I am going to be tempted to assemble a few of these myself, to have on hand for that glorious future day when I am retired and get back into modeling. If you need any help with the firmware just let me know. But somehow I am guessing you have it well in hand. 
12
« on: September 23, 2025, 10:02:16 AM »
Good work! I'm glad to hear you're still working on this, steadily if perhaps slowly. Not many people (in fact none) have ever managed to build a self-design board by post number 3 on a new forum! I'll look forward to hearing how it works.
13
« on: September 03, 2025, 11:26:29 AM »
Ok, I'm glad to hear that it's working. It's important to understand how the functions work, otherwise as I mentioned before it is certainly possible to create some function/trigger combinations that will result in unpredictable behavior.
On that topic I might mention once more that setting Acceleration and Deceleration levels by the Throttle command is yet again another one of these illogical combinations. It might function, but I am certain the result will not be what you want.
If you want to adjust the Acceleration or Decelaration levels while running, then you need to assign them to an analog aux channel on your radio. This is a valid approach which I have used many times myself, and it is very useful for observing in real time the effect that Acceleration and Decelerations will have on the driving of the tank.
However most people don't usually have 2 extra analog channels to devote to this, and besides, once you find the level that you like, it no longer needs to be adjusted. If for example you find that Acceleration level 4 is what you like, set it to level 4 under Profile 1 on the Driving tab of OP Config. Then you do not need any function-triggers at all. Profile 1 will always be active if a level is selected, and you will always be driving with Acceleration level 4. If you don't want any Acceleration or Decelaration constraints, simply uncheck those options in Profile 1 (uncheck Inertia and uncheck Momentum).
In short, you can use Acceleration and Deceleration effects if you want, or not. But it should be done using one of the methods I have just described. Assigning them to the Throttle command, or Engine speed, or other functions which by definition are related to acceleration and deceleration, is going to create very bizarre behavior, and may cause problems.
14
« on: September 01, 2025, 10:57:09 AM »
Hi Paul, those settings look fine, but I still see no reason why the smoker should not turn off.
Since we do not know what the problem is, we must experiment.
First, please remove these unnecessary functions and do not add them again:
- Airsoft/Mech Recoil Enable (you have already enabled it in OP Config)
- Smoker Disable
- Smoker Enable
- Drive Profile - Set to 1
- Set Acceleration Level
- Set Deceleration Level
Then load the prior firmware version as I mentioned before, and let me know if this makes any difference. I don't expect it will, but we need to rule out every possibility.
Next, please also try assigning turning on/off the engine directly with function triggers. First uncheck the "Auto-Start Engine with Throttle" option and set "Auto-Stop Engine when idle for" to 0 (zero) in OP Config in order to disable both those options, then use function triggers to assign a switch on your transmitter to the "Engine - Turn On" and "Engine - Turn Off" functions.
Let me know if this works, and if so on which step of the above three the change was detected.
15
« on: August 31, 2025, 10:40:13 AM »
Hi Paul, I don't see a function to turn on/off the engine, I assume you must have selected "Auto-Start Engine with Throttle?" And then you must have defined an "Auto-Stop Engine when idle for" delay? Can you can post your .OPZ file so I can examine all your settings? Anyway, I don't see why the smoker should not turn off, but I don't have a board to do any testing with here. The latest firmware update did make some changes to the smoker code. The change should not have any affect on the smoker turning off when the engine turns off, but just to be sure, it would be worth trying the prior firmware version and seeing if that makes any difference. The prior version is 0.93.78 and you can download it here. Right-click 0.93.78 and select "Save link as" to save it to your computer. Then flash it to the TCB with the "Use your own Hex" button on the Firmware tab of OP Config. Let me know if it makes any difference. A few other comments that are not related to your question, but I notice some unusual things about the function triggers you have created: - You are using the function "Airsoft/Mech Recoil - Enable," but these are enabled by default, so you don't need to assign a trigger to that function. The only reason you would use that function is if you were also using the "- Disable" function, and you wanted to switch between them. But you are not using the disable function, so this is unnecessary. You can delete that function trigger. - Likewise you are telling the TCB to set the Drive Profile to 1 whenever the engine starts. This is unnecessary, Drive Profile 1 is the default and is already selected. The only time you need to assign a trigger to Profile 1 is if you also have another trigger assigned to Profile 2, and you want to switch between them. You are not doing that, so telling it to use Profile 1 is unnecessary and you can delete that function trigger. - Finally, you have assigned functions to adjust acceleration and deceleration levels with engine speed. First of all, this immediately takes precedence over whatever acceleration and deceleration levels you have specified in Profile 1, so Profile 1 will never get used. But second of all, I don't think this associate makes any sense. OP Config lets you create any function-trigger pair that you want, but that doesn't mean they will be logical. What you have done means that the faster the tank goes, the slower it accelerates, and the slower it goes, the faster it decelerates. I have never tried such a thing, but I really doubt that is what you want. If you want to use any inertia or momentum, just set the desired levels in Profile 1, and that's it, you don't need to do anything else, and you don't need any function triggers. Profile 1 will be applied by default and the levels you have set in Profile 1 will be active whenever you are driving.
|
Show Posts