Featherweight Raven3 accel data?

[Buckeye]

I sent this inquiry to AdrianA, but I will post the question here, too. I launched my Raven3 for the first time. Fairly vertical flight, and the baro data is as expected. However, the acceleration data went bonkers. Attached are the fipa and some plots showing the issue.

Bottom line: The accel computed velocity< 0 well past the true apogee, and it kept merrily integrating positive altitude for another 12 seconds. As a result, the accel apogee is 5000 ft, while the true baro apogee was only 1700 ft. The #3 charge used for velocity-based apogee backup was pretty worthless, as the rocket was already half way to the ground. Good thing the backup was not needed.

What would cause the accelerometer to think it was still climbing, even though the rocket experienced the jolt of ejection and was falling under drogue for 12 seconds? I know that accelerometers really don't know their direction, but the accel data started off very wrong from liftoff. The first few seconds of accel data are supposed to be the most accurate, right?

I checked the real time data before the flight, after the flight, and after calibration. The readings didn't change much. Axial accel was between 0.8 and 1.2 as recommended.

Thanks.





View attachment firestick.i245.2017.04.23.FIPa

 

[mikec]

Looks to me like the usual issue of the accelerometer having a big accelerometer scale error, which has plagued the later production runs of the Raven 3. The Raven operates its accelerometer at voltage lower than the datasheet recommended value and some parts don't behave as well as others, though this one seems unusually far off. You likely won't be able to use accelerometer apogee detect.

Note that accelerometer altitude is never very accurate, but most Ravens do better than this on velocity.

 

[OverTheTop]

Have you run a calibration on the acclerometers? Maybe that might improve the situation.

 

[Buckeye]

Looks to me like the usual issue of the accelerometer having a big accelerometer scale error, which has plagued the later production runs of the Raven 3. The Raven operates its accelerometer at voltage lower than the datasheet recommended value and some parts don't behave as well as others, though this one seems unusually far off. You likely won't be able to use accelerometer apogee detect.

Note that accelerometer altitude is never very accurate, but most Ravens do better than this on velocity.

mikec, thanks for the input, even though it sounds pretty grim. I have studied many fipa files posted on this forum, and the accel altitude is often very close to the baro altitude and with good velocity/apogee detect. My goal is to use accel and velocity data to attempt to back out drag coefficient in the coast phase of more extreme flights than this one. I am not hopeful at this point.

I will wait for Adrian's response, and give it a couple more flights, but I am not gonna be happy if I plopped down $160 for a unit known to be "plagued" with "big accelerometer scale errors."

Yes, as I mentioned in post #1, I re-calibrated the accel, but the real time output looks no different than before calibration, so I am not sure if anything really improved.

 

[OverTheTop]

Yes, as I mentioned in post #1, I re-calibrated the accel,

Oops. Missed that!

 

[SpaceManMat]

I wasn't aware of a plauge of problems with the Raven.

its a bit hard to tell from the graph, can you confirm the accel values from before and after the flight?

 

[Buckeye]

I wasn't aware of a plauge of problems with the Raven.

its a bit hard to tell from the graph, can you confirm the accel values from before and after the flight?

Wow, lots of feedback from Down Under! Thanks guys.

The before/after accel data I am referring to are the setup/config tests performed when the unit is connected to the computer. The "real time" read out of axial G's fluctuates between 0.80 and 1.2, which the documentation says is OK. The "filtered" value holds pretty steady at 0.99 during the test.

 

[manixFan]

I don't quite understand your voltage plot. It looks like the voltage never recovers after apogee and then very quickly drops. What kind of battery were you using? The voltage looks like it drops to 1.4 volts which is obviously well under operating voltage. I would plot it with the main battery voltage instead of the pyro voltage.

There have been cases where the payload bay is under under drogue and spinning in a big circle. That can produce input to the accelerometer that mimics flight. So that might explain the upward graph after apogee.

It's also possible you just have a bad unit. I have several Ravens and have flown them on a variety of extreme flights with no issues. Adrian has been very good the couple of times I needed to have a unit fixed due to rough handling. If there is an issue with your unit I'm sure he'll make it right.

I use barometric apogee detection whenever possible though. Just a lot more reliable than accelerometer based, regardless of altimeter.


Tony

 

[mikec]

I am not gonna be happy if I plopped down $160 for a unit known to be "plagued" with "big accelerometer scale errors."

Obviously I don't speak for Featherweight but if the unit's this far off I think there's a good chance it will be replaced. The errors Adrian was talking about (you can find discussions here if you search enough) were large enough that he stopped recommending the use of accelerometer apogee mode, but they were typically only off a few seconds, and your case seems worse than that.

The error only manifests itself during acceleration so it can't be calibrated out at 1g and the calibration process won't help.

 

[SpaceManMat]

Obviously I don't speak for Featherweight but if the unit's this far off I think there's a good chance it will be replaced. The errors Adrian was talking about (you can find discussions here if you search enough) were large enough that he stopped recommending the use of accelerometer apogee mode, but they were typically only off a few seconds, and your case seems worse than that.

The error only manifests itself during acceleration so it can't be calibrated out at 1g and the calibration process won't help.

All accelormeters suffer from the same errors not a particular issue with the Raven, it is however highly flexibable and if you play with the configuration easy enough to stuff up.

This one does however have something wrong, pretty sure this is somehow not callebrated right. Which is why I'm interested in what the accelerometer was reading immediately prior to launch.

 

[UhClem]

All accelormeters suffer from the same errors not a particular issue with the Raven, it is however highly flexibable and if you play with the configuration easy enough to stuff up.

This one does however have something wrong, pretty sure this is somehow not callebrated right. Which is why I'm interested in what the accelerometer was reading immediately prior to launch.

The Raven suffers from problems because it runs the sensor at 3.3V rather than its specified 5V. The data sheet says it will work at 3.3V but its performance is only specified at 5V. The specifications for the ADC are the worst it has ever been my displeasure to read.

The data file shows that the prelaunch acceleration was 1G but that isn't surprising as it is tracking the 1G offset. What is more to the point is that at motor burnout the acceleration barely goes negative. Then when it should be approaching zero while coasting to apogee, it passes that and reaches 0.3G. Not unreasonable for a helium filled Estes Dude but otherwise completely wrong. Since the acceleration due to drag was so badly off, the integrated velocity didn't decrease as fast as it should.

Apogee detection is immune to scale errors because you start at zero and end at zero. Offset errors are a problem but since the data shows 1G prelaunch, that isn't the problem here.

 

[Buckeye]

I don't quite understand your voltage plot. It looks like the voltage never recovers after apogee and then very quickly drops. What kind of battery were you using? The voltage looks like it drops to 1.4 volts which is obviously well under operating voltage. I would plot it with the main battery voltage instead of the pyro voltage.

There have been cases where the payload bay is under under drogue and spinning in a big circle. That can produce input to the accelerometer that mimics flight. So that might explain the upward graph after apogee.

It's also possible you just have a bad unit. I have several Ravens and have flown them on a variety of extreme flights with no issues. Adrian has been very good the couple of times I needed to have a unit fixed due to rough handling. If there is an issue with your unit I'm sure he'll make it right.

I use barometric apogee detection whenever possible though. Just a lot more reliable than accelerometer based, regardless of altimeter.


Tony

Thanks, manixFan. I plotted the pyro voltages just to show the deployment events during the flight. Below is the main battery voltage. It looks rock solid to me, at a near-constant 4.15 volts. The battery is the 1S Lipo that is partnered with the PowerPerch.

 

[Buckeye]

Obviously I don't speak for Featherweight but if the unit's this far off I think there's a good chance it will be replaced. The errors Adrian was talking about (you can find discussions here if you search enough) were large enough that he stopped recommending the use of accelerometer apogee mode,

Well, the default setting for apogee backup is still accel velocity, and there are no cautionary notes in the documentation. Interestingly, I also previously used a Marsa54L, and it recommended accel velocity as primary apogee mode! Those results were not good either (not as bad as this Raven example), so I reverted back to baro apogee after suffering a couple very early apogee events. I won't be using accel velocity for any apogee event from now on.

 

[Buckeye]

All accelormeters suffer from the same errors not a particular issue with the Raven, it is however highly flexibable and if you play with the configuration easy enough to stuff up.

This one does however have something wrong, pretty sure this is somehow not callebrated right. Which is why I'm interested in what the accelerometer was reading immediately prior to launch.

Well, I guess I can't answer that as the altimeter was buttoned-up in the rocket immediately before launch! Regardless, calibration error is now ruled-out as the root cause.

I may have stuffed up the settings, but I don't think so. I carefully went over this logic, and all 4 events worked as prescribed.



edit: oh, you mean the pre-launch accel from the flight data, not the calibration procedure. Duh. The fipa file is attached in the first post, but that looks ok.

 

[jderimig]

Interestingly, I also previously used a Marsa54L, and it recommended accel velocity as primary apogee mode!

Marsa recommends Baro OR Accel (which ever is detected first) as the primary apogee detection mode. But there is nothing wrong with accel based apogee detection on the Marsa unless you go way off vertical (then the Baro will back you up).

If you have very early apogee accel events you should have contacted me to troubleshoot, there may have been a local problem with the board.

 

[mikec]

Well, the default setting for apogee backup is still accel velocity...

True. It used to be the other way around (accel for primary, baro for backup.) You're right that the manual doesn't say anything specifically about the scale problem and it ought to.

I would really try to get this unit replaced.

 

[manixFan]

Here's some comparison data from several of my units, all Raven 2's. But it does show that the accelerometer error is a lot bigger with longer, higher altitude flights:

L265:
[Altitude (Accel-Ft)]                         = Min: 0          Max: 30588
[Altitude (Baro-Ft-AGL)]                      = Min: -1         Max: 19403

935:
[Altitude (Accel-Ft)]                         = Min: 0          Max: 36355
[Altitude (Baro-Ft-AGL)]                      = Min: -13        Max: 23589

K627:
[Altitude (Accel-Ft)]                         = Min: 0          Max: 18734
[Altitude (Baro-Ft-AGL)]                      = Min: -2         Max: 15466

I55:
[Altitude (Accel-Ft)]                         = Min: 0          Max: 7259       
[Altitude (Baro-Ft-AGL)]                      = Min: 0          Max: 7826

Research N motor (BALLS)
[Altitude (Accel-Ft)]                         = Min: 0          Max: 15638
[Altitude (Baro-Ft-AGL)]                      = Min: -9258      Max: 13144

[Altitude (Accel-Ft)]                         = Min: 0          Max: 14420      
[Altitude (Baro-Ft-AGL)]                      = Min: -3         Max: 13137

Just as a point of reference. All flew with a redundant altimeter (generally a Stratalogger CF or an RDAS Compact) that matched the baro altitude of the Ravens within typical margin of error.


Tony

 

[Buckeye]

The Raven suffers from problems because it runs the sensor at 3.3V rather than its specified 5V. The data sheet says it will work at 3.3V but its performance is only specified at 5V. The specifications for the ADC are the worst it has ever been my displeasure to read..

You are the second person to mention this. This is troubling. The Raven is using parts out of their performance range?

The data file shows that the prelaunch acceleration was 1G but that isn't surprising as it is tracking the 1G offset. What is more to the point is that at motor burnout the acceleration barely goes negative. Then when it should be approaching zero while coasting to apogee, it passes that and reaches 0.3G. Not unreasonable for a helium filled Estes Dude but otherwise completely wrong. Since the acceleration due to drag was so badly off, the integrated velocity didn't decrease as fast as it should.

Bingo. This is the analysis I am looking for. I compare the accel output to a simulation to see what the altimeter should be doing. You are correct, the accel barely goes negative and does not asymptotically approach zero at apogee. Since the accel is completely wrong, so is the resulting velocity and altitude.

The consensus seems to be that I am due a replacement altimeter. Waiting for Adrian to respond (either on the forum or to the email I sent several days ago.) I am on a bad luck streak. The last 3 rocketry electronics I purchased all required immediate replacement - altimeter, USB interface, and now another altimeter.

 

[mikec]

You are the second person to mention this. This is troubling. The Raven is using parts out of their performance range?

IMHO as a long-time user, the Raven has the best price-performance of anything comparable on the market, I haven't had any problems with any of the ones I've bought, and I would buy more without reservation. There does appear to be an issue with newer batches of devices; it's presumed this is due to the use of the accelerometer ( https://www.analog.com/en/products/mems/accelerometers/adxl278.html ) outside the recommended voltage range, but within the "functional" voltage range. In a perfect world this wouldn't be the case. The first several generations worked fine with the same accel.

The ADXL278 is in last-time-buy status so either the design will be revised to use a different accel or the Raven will eventually become unavailable depending on Featherweight's stock of parts on hand.

 

[UhClem]

The ADXL278 is in last-time-buy status so either the design will be revised to use a different accel or the Raven will eventually become unavailable depending on Featherweight's stock of parts on hand.

I am a little surprised that there isn't a Raven4 yet. Adrian sent me an email four years ago saying he was starting on a redesign using a LPC micro-controller. Perhaps other projects got in the way.

 

[OverTheTop]

IMHO as a long-time user, the Raven has the best price-performance of anything comparable on the market, I haven't had any problems with any of the ones I've bought, and I would buy more without reservation.

+1. I have seven of them. Very reliable based on my usage.

 

[Buckeye]

IMHO as a long-time user, the Raven has the best price-performance of anything comparable on the market, I haven't had any problems with any of the ones I've bought, and I would buy more without reservation. There does appear to be an issue with newer batches of devices;

As I mentioned earlier, my whole reason for using the accelerometer is to get data for drag analysis. I thought (naively, I guess) that accels were robust and will easily give the feature-rich info I need. Plus, they are much more expensive than baro altimeters, so they have to be good, right? :wink: So far, my accel experience has been less than stellar.

I like all the data generated in the Featherweight FIPA, it is easy to export, and it carries enough resolution and significant digits for my subsequent calculations. I just need the accel to act reasonably during coast drag!

What does the $300 TeleMega offer over the less-expensive Raven and Marsa for accelerometer/data performance?

 

[tim cubbedge]

What does the $300 TeleMega offer over the less-expensive Raven and Marsa for accelerometer/data performance?

Telemega is $400 and has 6 pyro channels, 70cm Ham band for telemetry downlink with onboard GPS/

https://altusmetrum.org/TeleMega/

 

[Buckeye]

Sorry, $300 EasyMega. I don't need the Tele stuff, just interested in what the accelerometer can do.

 

[Adrian A]

I sent this inquiry to AdrianA, but I will post the question here, too. I launched my Raven3 for the first time. Fairly vertical flight, and the baro data is as expected. However, the acceleration data went bonkers. Attached are the fipa and some plots showing the issue.

Bottom line: The accel computed velocity< 0 well past the true apogee, and it kept merrily integrating positive altitude for another 12 seconds. As a result, the accel apogee is 5000 ft, while the true baro apogee was only 1700 ft. The #3 charge used for velocity-based apogee backup was pretty worthless, as the rocket was already half way to the ground. Good thing the backup was not needed.

What would cause the accelerometer to think it was still climbing, even though the rocket experienced the jolt of ejection and was falling under drogue for 12 seconds? I know that accelerometers really don't know their direction, but the accel data started off very wrong from liftoff. The first few seconds of accel data are supposed to be the most accurate, right?

I checked the real time data before the flight, after the flight, and after calibration. The readings didn't change much. Axial accel was between 0.8 and 1.2 as recommended.

Thanks.

Sorry your acceleration data was off for your flight. Looking closely at your data file, I think part of the error could have been avoided with a manual re-calibration before the flight, but not all of it.

The pre-launch accel average was about 1.1 Gs, which we would expect to be 1.0 Gs after a re-calibration. But 0.1 G error is 3.2 feet/second per second, so in the 10 seconds to apogee, that could account for about 32 feet/second velocity error if it were a constant offset.

However, the recorded velocity was 200 feet/second at apogee, so there is another source of error. Some Raven units have a nonlinearity in the response of the hardware that makes the scale factor measured in the +/- 1 G calibration different than the scale factor when it's measuring larger accelerations during the boost phase. That's probably the case here. When the rocket was at apogee and the drag would be near zero, your data shows +0.3 Gs measured when it should be slightly negative. If the zero-accel reading is that far off when the +1G and -1G readings are close to what they should be, then that's an indicator of nonlinearity in the hardware. I'll exchange your unit for you.

 

[Adrian A]

Looks to me like the usual issue of the accelerometer having a big accelerometer scale error, which has plagued the later production runs of the Raven 3. The Raven operates its accelerometer at voltage lower than the datasheet recommended value

Based on measurements I have made on problem units, the issue of nonlinearity is not from the accelerometer, but from the analog/digital converter in the Zilog 2480 microcontroller, which can have a few counts of nonlinearity error in a certain range of its output. If that range lines up with one of the +/- 1G calibration points, then a relatively small error can make a big difference when the accel is operating 20x (or 70x) outside of the calibrated range. Most units don't have a significant problem with this, but for the few that have a problem, like the one in this thread, I'll replace the units.

-Adrian

Edited to delete info that's redundant with the next post

 

[Adrian A]

IMHO as a long-time user, the Raven has the best price-performance of anything comparable on the market, I haven't had any problems with any of the ones I've bought, and I would buy more without reservation.

Thanks, Mike

There does appear to be an issue with newer batches of devices; it's presumed this is due to the use of the accelerometer ( https://www.analog.com/en/products/mems/accelerometers/adxl278.html ) outside the recommended voltage range, but within the "functional" voltage range. In a perfect world this wouldn't be the case. The first several generations worked fine with the same accel.

The accel or its operating voltage range is a reasonable hypothesis, but testing of problem units doesn't bear that out. The analog/digital converter sometimes has a nonlinear response over part of its range that can cause significant calibration errors when the nonlinearity lines up with one of the 2 calibration points. This has been an occasional issue since the Ravens were developed in 2010. I haven't noticed any uptick in the frequency of the problem recently.

The ADXL278 is in last-time-buy status so either the design will be revised to use a different accel or the Raven will eventually become unavailable depending on Featherweight's stock of parts on hand.

Very true. I got the very last production run of Raven3 altimeters fabricated a few weeks ago.

I am a little surprised that there isn't a Raven4 yet. Adrian sent me an email four years ago saying he was starting on a redesign using a LPC micro-controller. Perhaps other projects got in the way.

Yes, it's mostly been because of my day job and travel. I find I can only really focus on one design project at a time, and so there have been several times I have gotten started on an altimeter redesign but had to put it aside for long enough that the parts I picked out are no longer the best available when I'm ready to get started again.

In the last few months I have been pouring time and money into a new Featherweight product, but it's not an altimeter. I'll announce it when I get a prototype done that I'm happy with. I'm on my 6th iteration. After that I'll work on a Raven replacement. There will likely be a gap between the last Raven3 sold and the next Featherweight Altimeter.

 

[Buckeye]

.. I'll exchange your unit for you.

OK, fair enough. Thanks for the feedback. You have my email from 4/29/17. Please let me know offline how to proceed with the exchange.

 

[plugger]

In the last few months I have been pouring time and money into a new Featherweight product, but it's not an altimeter. I'll announce it when I get a prototype done that I'm happy with. I'm on my 6th iteration. After that I'll work on a Raven replacement. There will likely be a gap between the last Raven3 sold and the next Featherweight Altimeter.

I look forward to new Featherweight products Adrian. In my opinion they're the go-to for larger and more aggressive HPR flights. I was actually browsing your photobucket account just last week and got quite excited when I saw this with the filename of RavenPlus. Having an integrated mag switch would be beneficial to the computer imo. It would also be nice to supersede the need for a common rail.



I have 5 ravens currently. One V1, two V2 (single and dual axis accel), two V3 (single and dual axis accel). I've buried a few more, like last year when I had two in a 54mm to 38mm MD staging stack that I've never seen again.

Keep making them and I'll keep buying them...

 

[Adrian A]

Thanks. I had totally forgotten about that concept. I guess that was a battery interface board that fit underneath? These concepts eventually led to the Power Perch.

With the new tracker I'm working on, you shouldn't have to worry about losing more altimeters. I had a few false starts on the design, but last week an encouraging range test makes me more confident that the end result will be pretty awesome.