RDAS Compact Memory Failure - Ideas?

The Rocketry Forum

Help Support The Rocketry Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.

patelldp

Well-Known Member
Joined
Jan 23, 2009
Messages
5,647
Reaction score
100
So my RDAS Compact made a very expensive cross-country trip a few weeks ago with the hopes of going really high. Once it arrived, it started to do the "memory failure" bootload response of long, low frequency beeps. I just got it back into my possession and have started to troubleshoot the unit.

Symptoms:

1. The unit boots and reports "memory failure," the piezo sounds long, low frequency tones.
2. The unit is able to be seen by the software
3. I was able to successfully update the firmware to the unit
4. Whenever you attempt to download flight data or upload/download configuration profiles, the software freezes

Conclusion:

Flash Memory chip has failed, or the flash memory is corrupted and needs to be restored.

Request of an Expert:

Is there any way to wipe and configure the Flash memory? I poured over the software and manual and was unable to find anything. Before I scrap the unit, I want to make sure that it's not just a corrupted memory file or something. If the chip itself failed, I'm pretty sure this unit is garbage. Thanks in advance for the help.
 
Quick note...the AED e-mail doesn't work anymore. I also know that Jeroen is the brains behind the RDAS and I understand the difficulty there.
 
To start off, connect the RDAS to your PC via serial and connect to it with a Terminal program. Then turn on your RDAS. You should see boot messages from the RDAS booting. Hopefully there will be something useful that will point you in the right direction.
 
Dan -

Can you configure it to work with a baro apogee/drogue event, then chamber it to see if it will sequence and re-record over the corrupted data flash?
 
To start off, connect the RDAS to your PC via serial and connect to it with a Terminal program. Then turn on your RDAS. You should see boot messages from the RDAS booting. Hopefully there will be something useful that will point you in the right direction.

Good suggestion...here's the result:

RDAS Memory Failure.PNG

I think she's dead, Jim.
 
FWIW, I purchase a pair of new RDAS units from AED this year. The email thing should not necessarily be taken to mean they have closed up shop.

Understood, I was hoping for support from them. There's still a vendor that supplies them but I am unsure if they are working off stock or actively ordering, but this thread isn't focused on that (before anyone decides to post "I have them in stock!!!").
 
Dan -

Can you configure it to work with a baro apogee/drogue event, then chamber it to see if it will sequence and re-record over the corrupted data flash?

I wish. It appears that step one of the bootloader sequence is to check the memory. If that fails, it precludes anything else from working. There's volatile and non-volatile memory...looks like the non-volatile chip is trash.
 
Not having seen it, is the chip in question available, and something you could remove and solder a new one on?
 
If the problem is with the flash memory then that is a factory repair. Unless you have a copy of the bootloader and the hardware to write it into the flash chip.

But it might not be the flash as it could be the 32K SRAM chip. (corner of PCB on capacitor side) Get a magnifier and examine the pins on that chip for obvious problems. It could just be a loose connection. If the SRAM chip is bad it is still in stock at Mouser. (Alliance AS7C256)

That screen capture suggests a SRAM memory check. If it were me writing the code, I wouldn't be wasting flash erase cycles on a stinking startup check. I would do a CRC on the code instead.
 
If the problem is with the flash memory then that is a factory repair. Unless you have a copy of the bootloader and the hardware to write it into the flash chip.

But it might not be the flash as it could be the 32K SRAM chip. (corner of PCB on capacitor side) Get a magnifier and examine the pins on that chip for obvious problems. It could just be a loose connection. If the SRAM chip is bad it is still in stock at Mouser. (Alliance AS7C256)

That screen capture suggests a SRAM memory check. If it were me writing the code, I wouldn't be wasting flash erase cycles on a stinking startup check. I would do a CRC on the code instead.

I appreciate the help. I'll take a look at the chip this evening when I get home. I primarily purchased this altimeter as a data collection unit but it has given me nothing but fits since I bought it. I guess that's what you get with old tech that's been kicking around for a while.
 
I'm working on a 3 axis accelerometer and micro controller pair (breakout) for go/no go staging/sustainer ignition that will come in at about $30 bucks retail and will be about the size of two stacked quarters. I'm working on the code right now. It's great to see the board tilt and the LED go out!

What data were you looking to collect? I may be able to steer you into the right direction for components and code. Breakout boards are so small and simple to program anymore that it makes sense to build and tailor your own systems if one is so mechanically inclined.
 
I'm working on a 3 axis accelerometer and micro controller pair (breakout) for go/no go staging/sustainer ignition that will come in at about $30 bucks retail and will be about the size of two stacked quarters. I'm working on the code right now. It's great to see the board tilt and the LED go out!

What data were you looking to collect? I may be able to steer you into the right direction for components and code. Breakout boards are so small and simple to program anymore that it makes sense to build and tailor your own systems if one is so mechanically inclined.

Recording the output from a pressure transducer. I can do it with both my two Ravens and two AIM Xtra 2.0's, just need to figure it out. The RDAS performed very similarly to a Dataq.
 
I'm working on a 3 axis accelerometer and micro controller pair (breakout) for go/no go staging/sustainer ignition that will come in at about $30 bucks retail and will be about the size of two stacked quarters. I'm working on the code right now. It's great to see the board tilt and the LED go out!

Do you realize that you cannot use a 3-axis accelerometer to detect tilt in flight?
 
3 axis is all you need. I'll let you know when it's done!

It's not about the number of axes. An accelerometer cannot measure tilt in flight because in flight there is no gravity reference.
 
3 axis is all you need. I'll let you know when it's done!
While it's been awhile since I worked on it you need a 9 DOF IMU or really an 'Attitude and Heading Reference System' (AHRS). Of course the 9 DOF's come from 3 axis accelerometers, magnetometers, and gyros. An AHRS nearly always has baro pressure as well. A good example is here:

https://github.com/ptrbrtz/razor-9dof-ahrs/wiki/Tutorial

I used a very nice one from:

https://www.vectornav.com/home

for a non-rocketry project I worked on. They now have a 2 GPS unit that uses GPS interferometry techniques to compute a heading without having to rely on magnetic compass data. It's a bit spendy for our purposes though.


Tony
 
...deleted to stop hijacking thread, sorry...
 
Last edited:
Getting back on track-

I still have and fly my RDAS Compact. If there is anything I can do to help out I'd be happy to lend a hand. As a topical aside, there here's a thread about using a Raven to collect data in flight by using the voltage recording capabilities of the pyro channels:

https://www.rocketryforum.com/showt...nFlutter-InFlightChamberPressureData-RedCloud

It's pretty light on actual details but it is a good proof-of-concept on using the Raven as a data recorder.


Tony
 
Getting back on track-

I still have and fly my RDAS Compact. If there is anything I can do to help out I'd be happy to lend a hand. As a topical aside, there here's a thread about using a Raven to collect data in flight by using the voltage recording capabilities of the pyro channels:

https://www.rocketryforum.com/showt...nFlutter-InFlightChamberPressureData-RedCloud

It's pretty light on actual details but it is a good proof-of-concept on using the Raven as a data recorder.


Tony

Thanks Tony. It should be pretty simple because the Raven can run on any voltage up to 16V. The individual channels measure the voltage during flight, so hooking a 5V transducer with the positive lead to the measurement channel's terminal and the negative lead to the negative terminal should result in recording of pressure data.

The primary concern is that you will likely lose the ignition transient. From the instructions:

"The Raven will detect liftoff when accelerometer readings in excess of 3 Gs integrate to a 3 mph upward velocity."

The nice thing about the RDAS is that one could trip the unit artificially using the break wire functionality. I had plans to make a "skid" of sorts that would attach to the fore end of the motor and include my transducer, voltage converter (my transducer requires 28V excitation), and RDAS. Break the continuity on the channel as your last act when walking away from the pad and let it do its thing.

This is my second RDAS that has had issues, so if I were to do it again I'd find a Tiny, but I think I'm just about done.
 
The primary concern is that you will likely lose the ignition transient.
The Raven still records pre-liftoff data, look at the accelerometer channels for a particular flight. It's always taking data pre-liftoff and saves some amount from a buffer to flash at liftoff detection.

Of course, the sampling rate is low on the channels you could use for this.
 
It's not about the number of axes. An accelerometer cannot measure tilt in flight because in flight there is no gravity reference.


Sorry for referring to it as an accelerometer.

I'm using this little guy:

https://www.ebay.com/itm/121833787578?_trksid=p2055119.m1438.l2649&ssPageName=STRK:MEBIDX:IT

And an Adafruit Trinket:

https://www.adafruit.com/product/1500

The accelerometer data is used to help smooth out the gyro data through a Kalman filter. Drift is not a concern as flight times are so short. The code started off as a gimbal code sketch that I am modifying. Wired between the flight computer and igniter, and the igniter lead being controlled (open/closed) by a small transistor that will be controlled by the small current microcontroller GPIO pins I hope to create a cheap failsafe for staging/airstarts.
 
Sorry for referring to it as an accelerometer.

I'm using this little guy:

https://www.ebay.com/itm/121833787578?_trksid=p2055119.m1438.l2649&ssPageName=STRK:MEBIDX:IT

And an Adafruit Trinket:

https://www.adafruit.com/product/1500

The accelerometer data is used to help smooth out the gyro data through a Kalman filter. Drift is not a concern as flight times are so short. The code started off as a gimbal code sketch that I am modifying. Wired between the flight computer and igniter, and the igniter lead being controlled (open/closed) by a small transistor that will be controlled by the small current microcontroller GPIO pins I hope to create a cheap failsafe for staging/airstarts.

Cool. But don't use the accelerometer after launch. You can use the accelerometer to measure the initial pad angle but after that it is useless and actually unwanted for tilt. If you are using the Invensense Embedded Motion Driver don't enable the 6-axis DMP quaternion but instead use the 3-axis. Good luck with your project!
 
Thanks! I have never done this before and am slowly learning. I am stuck right now with trying to figure out how to orient the IMU vertically rather than horizontally and provide the same output. Vertical arrangement of breakout boards affords easier installation in small compartments, e.g. space between motor mount and airframe between centering rings in an appropriately sized vehicle.

Thank you for the suggestion. The DMP is actually what drew me to this IMU vs another. I wanted the form factor as small as possible and the MPU6050 with the Trinket fit the bill vs arduino nano or pro-mini, etc.. The people over at I2cdevlibs are quite knowledgeable and helpful as are the github community. Without them I wouldn't have a clue with this stuff!
 
No. It would seem we have someone else who doesn't understand gravity.



I'm not a very smart guy, I'll be the first to admit. I'm "pretty" good at a lot of things but not REALLY good at anything.

But I learn.

So I'm not sorry that I'm not a genius, or a bad-ass physicist, engineer, or some crazy robotics supertechnician like you are. I am just trying to develop a simple, affordable, useful tool for myself and fellow hobbyists that may even prevent damage or injury to something or someone someday. Punk.
 
Dave likes to post retorts without offering any useful information. Better to just ignore those types of posts and respond to those who post helpful info like John. It's the Internet - anyone can post but only you can choose who to ignore.


Tony
 
Last edited:
Cool. But don't use the accelerometer after launch. You can use the accelerometer to measure the initial pad angle but after that it is useless and actually unwanted for tilt. If you are using the Invensense Embedded Motion Driver don't enable the 6-axis DMP quaternion but instead use the 3-axis. Good luck with your project!

This is a dead thread, so since we are already on the same page:

I would really like to use the accelerometer throughout the launch. Not only to establish the gravity vector but to assist the gyro/drift during flight. Unfortunately, as I'm sure this was the reason you alluded to the omittance of the accelerometer during flight, accelerometer vibrations during flight muck up raw data values rendering the IMU worthless in the air.

But what if I added a rolling average of the accelerometer values before the kalman filter to divide the raw accelerometer values by 25, thus using a large gyro value and only a small, recurrent accelerometer value?

See:

angle_pitch = angle_pitch * 0.9996 + angle_pitch_acc * 0.0004;
angle_roll = angle_roll * 0.9996 + angle_roll_acc * 0.0004;

Why wouldn't this work?

Why would it be easier to establish Z on the ground and then disable the accelerometer altogether?
 
This is a dead thread...I would really like to use the accelerometer throughout the launch.
Dead because you derailed it. Next time I suggest you start a new thread.

Two questions for you to think about:

1) rocket is free falling, nose down. What does the accelerometer read?

2) rocket does a 180 right after launch and is thrusting nose down. What does the accelerometer read?
 
Back
Top