You are receiving this notice because our records indicate that you purchased an airspeed sensor from 3D Robotics. Our ongoing product testing has turned up a rarely occurring issue that can cause poor performance of the airspeed sensor.
There is no further action required if:
You are not using an airspeed sensor with APM 2.5
You are using an APM 1.0 or APM 2.0
When using the APM 2.5 with a telemetry radio and GPS, the current draw of these two devices may cause inaccurate airspeed sensor readings. An immediate fix for this is to disable the airspeed sensor in the Mission Planner.
For those who do need to use the airspeed sensor along with GPS and telemetry radio, and are affected by this issue, you can return your APM 2.5 to us so that we may replace a single component on your board and remedy this issue entirely.
We will do this at no cost to you. Simply reply to this message, and we will issue you a return merchandise authorization (RMA) with instructions on shipping your APM 2.5 back to us.
We apologize for any inconvenience this may have caused you and look forward to continuing to provide you with the best quality autonomous products at the most affordable prices.
The 3DR Team
if the problem is real is what it is and how to fix it yourself?
@alexey, i need to have the fuse replaced on my APM2.5 since i received an email. can you please instruct me how to get RMA ticket for getting the fuse replaced on my APM2.5. thanx
Has anyone else sent their board in yet? I sent mine in via the FedEX Returns system Thursday June 20th and it arrived at 3DR on Thursday June 27th. I didn't expect it to take that long in transit; I.m on vacation this week and had hoped to do some flying. When the email said 3-5 days I had expected it to take a week to ten days total with shipping.......well shipping took a week, so I'd like to know what others have experienced. Has anyone gotten their board back yet, and if so how long did it take?
I am especially annoyed by the delay, because I noticed this issue well before the RMA was announced. I use airspeed sensor, GPS, Power Module, MinimOSD, RFD900. I originally powered the other devices from external supply to overcome this, but now that the RMA was announced, I want it fixed!
What is the status, and why have my 4 replies to the original email, and additional emails to the "help" address been ignored for this long?
Please, some feedback!
PS: I did lose a plane due to this issue before my temporary fix - my receiver was powered by the glitchy output rail too, which didnt like the voltage fluctuation, occasionally causing a random PWM on a channel... sometimes the mode channel... you can imagine the confusion that happens with a random mode change at low altitude. Well, it also could have been a reboot or an airspeed fluctuation causing the unexpected mode change. I also lost a bunch of servos before I fixed it, due to the PWM glitching. :(
You can see I blogged about this to warn others back in Jan, Apr and May: http://www.rcgroups.com/forums/showthread.php?t=1592106&page=91 #1362
i powered the RD900 via ESC's BEC . Now the airspeed sensor is giving correct readings. no problem at all. earlier the airspeed readings were jumping wieredly even when speed was zero. thanx all for such a simple solution to a serious problem. excessive electrical load on APM2.5 can even reboot it while in flight. so i ma not sending my APM2.5 for fuse replacement.
@moglos, the servo bus current does not passes through fuse F2. when you connect ESC to servo output rail the ESC powers the servoes directly without going through the F2 fuse. but please double chk. that is my conclusion.
servoes are anyway powered by the motor ESC if you have the tiny jumper on the APM2.5 removed. the most power hungry device is 3DR and Radio control receiver. the best is that they are both powered by a seperate BEC. a good one can be bought for $10. a 5v/3A BEC would serve the purpose and can be powered by the balance port of the flying battery. GPS and airspeed sensors draw a meager 10mA so they do not effect Fuse F2.
Just to be clear, if I leave JP1 open and I power both the input and output from my BEC, then this should not be a problem? Or are the IO pins and telemetry radio still powered through this diode?
Alternatively, I can cut the telemetry radio cable, and hook it up directly to the BEC power. I guess I can do the same with the airspeed sensor power cable too?
Or do I have it all wrong?
@Alexey Kozin, I am having seriuoss problem with my airspeed data since i am using APM2.5 with RD900 and also powering the Radio control Rx. i need a ticket issued so that i can send the APM2.5 for fuse replacement of fuse back to san diego. i have written to support but still waiting for ticket. unless i get a ticket number i cannot mail the APM2.5. thanx ravi
I posted a bit of background info on drones-discuss, which may help explain where this change is coming from
I can't help you with the components, but I can give you a bit of
background that may help you decide if you need the change.
The problem was first noticed when users were running relatively
powerful telemetry radios off their telemetry port. For example, if you
run a RFD900 radio at full power (30dBm), it will draw 900mA when
transmitting, then almost zero a moment later. That ramp up and down of
the power demand on the 3DR power brick through that fuse could cause
the voltage on the AVR2560 MCU to vary by far more than it should. That
led to the voltage reference on the airspeed port changing rapidly,
which led to noisy airspeed results and in extreme cases could have
taken the AVR2560 voltage below its safe level.
Apart from the fix 3DR offers there are other ways you can avoid the
problem. First off, you can monitor the HWSTATUS Vcc board voltage in
your ground station (eg. MissionPlanner) and see if it is in fact
varying significantly when on battery power with a telemetry radio. If
its not varying much (eg. 0.1V or so) then you don't have a problem.
If it is varying then you have some other options:
1) turn down the power on your telemetry radio. You may not need all
the power its drawing depending on the range you need
2) power the radio externally. For example, the RFD900 has a jumper for
external power. You can do the same on a 3DR radio with a bit of
I should also mention that recent code changes make the impact of this
problem on airspeed much less than it was with the 2.72 ArduPlane
firmware. We previously did voltage scaling against Vcc, which was not
correct, as the sensor is ratiometric. That made the problem much worse
than it should have been. In 2.73 the airspeed noise isn't as bad, and
also drops rapidly at higher airspeeds. It's only really an issue at
lower airspeeds (say under 9 m/s).
I also wonder if a strategically placed capacitor would help? I'm not an
electronics person, so I don't really know. Maybe someone else could