Hello guest, if you read this it means you are not registered. Click here to register in a few simple steps, you will enjoy all features of our Forum.
This forum uses cookies
This forum makes use of cookies to store your login information if you are registered, and your last visit if you are not. Cookies are small text documents stored on your computer; the cookies set by this forum can only be used on this website and pose no security risk. Cookies on this forum also track the specific topics you have read and when you last read them. Please confirm whether you accept or reject these cookies being set.

A cookie will be stored in your browser regardless of choice to prevent you being asked this question again. You will be able to change your cookie settings at any time using the link in the footer.

Thread Rating:
  • 1 Vote(s) - 5 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Testing, Heatsoaking, Burning In...
#1
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.
Builds: Mini-Quad  -  Tricopter 
A Blog

[-] The following 6 users Like Aaron's post:
  • Drone0fPrey, Oscar, fftunes, sloscotty, unseen, Tom BD Bad
Reply
Login to remove this ad | Register Here
#2
Excellent advice Aaron!

It's a fact that most electronic components that are going to fail will do so within the first 30 days of use, and of those 30 days, a large number of failures happen within the first few hours. Anything you can do to catch these failures before the parts are integrated into a build saves time, frustration and bad language. Smile
[-] The following 2 users Like unseen's post:
  • Drone0fPrey, fftunes
Reply
#3
Good read!

In my builds i usually test component groups before final assembly. As my builds are simple (no OSD for example, no gps, baro etc) this boils down to 3 groups:
- drive train (power distribution / escs / motors)
- communication (fc / firmware settings / rx)
- video train (fpv cam / filter / vtx)

But as i don't do long testing sessions, i just stay careful say the first 10 flights or so, means not flying too far, or very high...
[-] The following 1 user Likes fftunes's post:
  • unseen
Reply
#4
Great advice! Thank you Aaron Thumbs Up
The Obsession IS Real!
My Youtube and Instagram links
Reply
#5
With a new Flight Control arrived here's a picture of it having a really basic heat-soak test.

Yep it's in a small bag mainly so it doesn't accidentally short out on anything - it's plugged in on USB to iNav running the Sensor screen - this basically has the FC reading the sensors and piping the output to USB.  Nothing strenuous but it should be able to do this for hours.

Sometimes the App will crash so don't think that having a constant output is important, but rather the ability to run for 30-40 minutes is.  Likewise restarting immediately when the software is restarted etc.

[Image: ekYf0aDl.jpg]

When I'm happy this is OK I'll move on to connecting it into the aircraft (Tricopter in this specific case) and repeat again with the RX powered and motors running (at idle) for a pack or two...
Builds: Mini-Quad  -  Tricopter 
A Blog

Reply
#6
Are the plastic bags a good idea as they will generate static electricity?
Reply


Possibly Related Threads...
Thread Author Replies Views Last Post
  Antenna Testing - Help identify this part handlex84 6 335 17-Mar-2023, 06:13 PM
Last Post: SnowLeopardFPV
  What would be reasons for a quad burning every VTX I put in it? zelando 8 729 10-Dec-2022, 09:23 PM
Last Post: matt0725
  Testing esc damage Smoses221 4 1,035 14-Jul-2020, 12:49 AM
Last Post: voodoo614
  Figuring out short circuit / testing suspect ESCs beatbox 3 915 17-Dec-2018, 01:17 AM
Last Post: SnowLeopardFPV


Login to remove this ad | Register Here