91
« Last post by LukeZ 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.
92
« Last post by LukeZ 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.
93
« Last post by NielsD on October 27, 2025, 02:08:26 PM »
Thanks again!  Als thanks for thinking along on the heatsinks. I ordered some of the 9x9x12 heatsinks, with which I have enough height to clear the capacitors. I also granted you access to the Gitlab project, so please check if it works. One quirk with the Multisense output is that it seems to saturate to maximum ADC value so now and then. It doesn’t stay in that error for long, so I think it is not a real error that is triggered. On the other hand, I also don’t expect it to draw 14.3A (which should be 14 [mA/count] multiplied by 1023 [counts]). This is something I have to do some measurements on to solve I guess.
94
« Last post by LukeZ 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.
95
« Last post by NielsD on October 26, 2025, 10:25:32 AM »
I implemented the Multisense functionality and uploaded the code here: https://gitlab.com/niels.d/scout-miniThe readme still needs some updating and also the board files need to be uploaded (but they are on another laptop and I have to clean them up a bit). I am also looking for heatsinks, but couldn't find any suitable ones in 10x10mm and enough height to protrude above the capacitors (which are a bit of an airflow obstruction unfortunately). Maybe someone here has a tip for where to get those?
96
« Last post by NielsD on October 26, 2025, 08:55:30 AM »
Thanks for the compliments! No, this was not my first layout. I'm an aerospace electronics engineer, so this is a nice hobby project for me to also use my technical skills. Today, I got the Scout ESC Mini working for the first time using two PWM inputs (left stick = left track, right stick = right track): https://www.youtube.com/shorts/XLSogyMyqIEI have worked out how to use the Multisense functionality, but I still have to test it. Basically it clips to 5V to indicate an error and if it's not 5V, it's lower and proportional to the motor current. I will look into that today and see if I can get it to work properly. Also, the tank seems to be running a bit slow compared to the single Tamiya motor, but I guess that's due to the gearbox.
97
« Last post by LukeZ 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.
98
« Last post by Foxhood 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!
99
« Last post by LukeZ 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.
100
« Last post by Dean Rauch on October 02, 2025, 03:36:12 PM »
Hello
The track pins are made from 1.8mm hard stainless steel wire. I straightened the wire and cut them to length with a crude jig. Next time I would try to find straight sections as bending it was not fun.
All components were sourced from AliExpress
|
Recent Posts