17-Jun-2017, 02:30 AM
I've made mention of this a few times in my build threads that I generally Bench Test or heat soak test all my components within reason either before or through my build processes.
As a few people have asked "what does that involve" I figured it's worthy of a topic here.
Why?
The first and most obvious answer is to make sure the component works before you've committed it into a build in a way that is time consuming or annoying to undo if it is dead on arrival (and lets face it that can happen with poorly packaged cheaply made electronics from the other side of the world).
The second is to make sure that basics like firmware/software can communicate with your computer for configuration and tuning before you are just about to venture into the field to fly.
There's some other reasons as well that are less obvious that those above.
A long period of (many hour) operation will thoroughly warm up components, you'll be able to see if your barometer, gyros and other sensors remain consistent or not in relatively controlled conditions.
You'll see if there's a a software related "crash" after a few minutes of run-time without constant reconfiguration activities rebooting the the component.
You'll build up knowledge on the configuration software, the other hardware being connected into your build and hopefully work through all the integration issues before you and ready to fly.
In summary there's nothing worse than having a build completed and looking ready for flight only to discover that all the control electronics are messed up.
When?
I tend to do this as parts arrive.
When you get a new flight controller plug it into your computer via the USB, make sure it communicates with the software, work out the magic solution to flashing your preferred control software (or choose to not flash it at this stage) at whatever version you are comfortable with. At this stage I will generally fix the FC into a position, take not of the Gyro/barometer reading and leave powered on for 15-30 minutes, check the readings again, then power off.
I tend to do the same with ESCs when they arrive, rigging up temporary patch leads and flashing to the latest firmware. At that point I may never update them again, but what I know that that point is that there's a genuine clean BLHeli installed, all are the same version and they were able to communicate with the flashing process. Its far easier to do this on the bench than it ispost-build when you discover that some ESCs can't be flashed vis the flight controller.
Once I've started building I'll do more testing. When the receiver arrives I'll test that the receiver and FC will communicate again just using USB power to the FC.
PDB/BECs I test on the bench when they arrive. I use a multimeter to test the regulator outputs and then simply let them power a dummy load for a bit of time.
How Long?
For the most part all any of us are needing to be sure of is that the components in a build will work effectively through the entire flight time. So if you think you're going to get 7 minutes from a battery charge make sure you test every component for 10-15 minutes. I have left FCs plugged in for hours just to see how things go and mucked around with blowing warm air over them to increase heat stress.
The PDB/BEC may get quite hot when running under full load so it doesn't hurt to really load these up while running off a battery or bench power supply. The components in these should be rugged enough for the job, but sometimes things fail as they approach their voltage or current limits, and it's much safer to stress them on the ground!
Once I have a build finished I'll generally plug in a battery and run the motors (sans props) for about 10-15 minutes and mid-throttle - the load is much less so you will get a long run time - I then swap the battery and go again.
Yes I guess I'm adding hours to my builds this way but I can say that since implementing these tests and checks I haven't had to disassemble and second guess my builds. Unlike my first one which was together and apart multiple times before I flew.
As a few people have asked "what does that involve" I figured it's worthy of a topic here.
Why?
The first and most obvious answer is to make sure the component works before you've committed it into a build in a way that is time consuming or annoying to undo if it is dead on arrival (and lets face it that can happen with poorly packaged cheaply made electronics from the other side of the world).
The second is to make sure that basics like firmware/software can communicate with your computer for configuration and tuning before you are just about to venture into the field to fly.
There's some other reasons as well that are less obvious that those above.
A long period of (many hour) operation will thoroughly warm up components, you'll be able to see if your barometer, gyros and other sensors remain consistent or not in relatively controlled conditions.
You'll see if there's a a software related "crash" after a few minutes of run-time without constant reconfiguration activities rebooting the the component.
You'll build up knowledge on the configuration software, the other hardware being connected into your build and hopefully work through all the integration issues before you and ready to fly.
In summary there's nothing worse than having a build completed and looking ready for flight only to discover that all the control electronics are messed up.
When?
I tend to do this as parts arrive.
When you get a new flight controller plug it into your computer via the USB, make sure it communicates with the software, work out the magic solution to flashing your preferred control software (or choose to not flash it at this stage) at whatever version you are comfortable with. At this stage I will generally fix the FC into a position, take not of the Gyro/barometer reading and leave powered on for 15-30 minutes, check the readings again, then power off.
I tend to do the same with ESCs when they arrive, rigging up temporary patch leads and flashing to the latest firmware. At that point I may never update them again, but what I know that that point is that there's a genuine clean BLHeli installed, all are the same version and they were able to communicate with the flashing process. Its far easier to do this on the bench than it ispost-build when you discover that some ESCs can't be flashed vis the flight controller.
Once I've started building I'll do more testing. When the receiver arrives I'll test that the receiver and FC will communicate again just using USB power to the FC.
PDB/BECs I test on the bench when they arrive. I use a multimeter to test the regulator outputs and then simply let them power a dummy load for a bit of time.
How Long?
For the most part all any of us are needing to be sure of is that the components in a build will work effectively through the entire flight time. So if you think you're going to get 7 minutes from a battery charge make sure you test every component for 10-15 minutes. I have left FCs plugged in for hours just to see how things go and mucked around with blowing warm air over them to increase heat stress.
The PDB/BEC may get quite hot when running under full load so it doesn't hurt to really load these up while running off a battery or bench power supply. The components in these should be rugged enough for the job, but sometimes things fail as they approach their voltage or current limits, and it's much safer to stress them on the ground!
Once I have a build finished I'll generally plug in a battery and run the motors (sans props) for about 10-15 minutes and mid-throttle - the load is much less so you will get a long run time - I then swap the battery and go again.
Yes I guess I'm adding hours to my builds this way but I can say that since implementing these tests and checks I haven't had to disassemble and second guess my builds. Unlike my first one which was together and apart multiple times before I flew.