- Joined
- Sep 5, 2009
- Messages
- 3,527
- Reaction score
- 1,645
Nice. On the back side, is there one threaded rod to hold the sled/avbay?
Next-Gen Raven Development Thread
- Thread starter Adrian A
- Start date
Help Support The Rocketry Forum:
Nice. On the back side, is there one threaded rod to hold the sled/avbay?
There is a 1/4 brass tube (unused launch lug from an old kit) that slides over 1/4 threaded aluminum rod that runs through the e-bay. I started using all aluminum components a while ago to save weight and avoid issues with the magnets. I bought several threaded alum rods along with nuts and washers from Graingers. Fortunately there is one near my house so I can just pick up items to avoid shipping. The strength of the alum rod is surprising given its weight.
Even with the big magnet I didn't have any trouble with both switches being activated at the same time.
Tony
If I incorporate a remote arming feature I will likely do it over LoRa with some type of combined Raven/Featherweight GPS integration
Thanks, Tony.
Good point about the airframe blocking WiFi. It's not well-known that airframes that block RF signals will pass a steady-state magnetic field that is used to toggle the Featherweight magnetic switch. Putting the mag switches far apart and close to the edges is a good configuration.
Hmmm, it would be really cool if the new altimeter and tracker could communicate with each other, similar to a few other offerings on the market. Especially if the tracker could relay data from the altimeter for a much better readout of altitude and speed since it does not rely on GPS lock during boost. Even more interesting would be if the GPS/tracker could inhibit/enable certain altimeter events via radio without need for wires.
Lots of possibilities.
Tony
Having the altimeters status available via telemetry is a great comfort before launch. I normally connect the Raven supplies to my spare inputs on the TeleMega for that extra degree of confidence. Extra analog inputs on any telemetry system are EXTREMELY handy 
. Have you considered an extra peripheral PCA that connects to the GPS system and has extra inputs and outputs? A bit of a limited market I suppose, and you have so much spare time . My sympathies with all these request for features and functions on your products!
. Have you considered an extra peripheral PCA that connects to the GPS system and has extra inputs and outputs? A bit of a limited market I suppose, and you have so much spare time . My sympathies with all these request for features and functions on your products!
Today I fixed the last of the bugs I can find with the simulated flights. Yay! Hopefully this week I'll have time to prep a test rocket to fly it in next weekend, probably the Tripoli Colorado launch.
The accelerometer seems to have held its calibration pretty well over the last few months, which is encouraging. I'm hoping it's also more linear than what's in the Raven3, so that the velocity measurement and accel-based apogee detection is more accurate. I'll fly it alongside a Featherweight GPS in order to compare the velocity accuracy.
The accel is currently set for a +/- 100G range, but I found out on another project that when using the sensor's max sample rate, the only difference between the 100G range and the 400G range is that the sensor shifts the output left by 2 bits and pads the LSBs with zeros. (!) I would still want to keep the current 11-bit size in the flash in order to avoid making a lot of large changes, but if I wanted to change to 200G range I could do that if we're willing to cut back the resolution by 2x.
The accelerometer seems to have held its calibration pretty well over the last few months, which is encouraging. I'm hoping it's also more linear than what's in the Raven3, so that the velocity measurement and accel-based apogee detection is more accurate. I'll fly it alongside a Featherweight GPS in order to compare the velocity accuracy.
The accel is currently set for a +/- 100G range, but I found out on another project that when using the sensor's max sample rate, the only difference between the 100G range and the 400G range is that the sensor shifts the output left by 2 bits and pads the LSBs with zeros. (!) I would still want to keep the current 11-bit size in the flash in order to avoid making a lot of large changes, but if I wanted to change to 200G range I could do that if we're willing to cut back the resolution by 2x.
That's great news, I hope the test flights go well. At BALLS I did run into an issue with my Raven altimeters. The beeper is quite a bit quieter than others (like on the Perfectflites I use as backup to the Raven) so it made it hard to hear the Raven's status. This was especially true with a rocket that had fairly beefy walls for both the body tube and altimeter bay. I don't know how much flexibility you have sourcing the beeper but something to keep in mind for us older flyers whose hearing isn't what it used to be.
Thanks,
Tony
Thanks,
Tony
Last weekend the Raven4 was two-for-two doing deployments on its first two flights.
The rocket was a mid-power rocket I'm using for some initial testing. It should be able to handle a D10 through an F240.
I started with an E30, and chickened out a bit to keep the motor deployment charge in. The motor charge fired early, as you can see from the graph below:
When the motor deployment fired, the rocket was still moving upward pretty fast and did some funky tumbling, so I'm happy that both the accel-based apogee and the baro-based apogee seem to have been pretty much on the money.
In the graph below, you can see the details of when the motor ejection fired and the subsequent tightening of the apogee shock cord. Then later, at the actual apogee, the apogee charge fired which gave the upper section a little kick even though it was on its own, since the charge was still taped to the back end:
Next up, I flew an E75 Vmax (in a cute little 1-grain CTI case), and I removed the motor ejection charge before the flight this time. For this flight, the burn was only about 0.3 seconds and the Gs peaked at about 25. The accel-based and baro-based apogee estimates were still quite good. I put a pretty aggressive low-pass filter on the barometric apogee detection to make sure that transients don't cause a premature apogee detection. That also causes a delay which allows the rocket pass clearly through apogee for a good max altitude estimate. I'm happy to see that the accel-based apogee detection was even closer to apogee than the baro estimate was. Accelerometer inaccuracy has been an issue with the Raven3, and the Raven4 looks like it has improved in this area.
Zooming in on the burn, the lateral sensor shows a little bouncing around of the rocket while it was on the rail, and then as soon as it left the rail (when the accel-based altitude was about 7 feet) it took a little wobble.
The rocket was a mid-power rocket I'm using for some initial testing. It should be able to handle a D10 through an F240.
I started with an E30, and chickened out a bit to keep the motor deployment charge in. The motor charge fired early, as you can see from the graph below:
When the motor deployment fired, the rocket was still moving upward pretty fast and did some funky tumbling, so I'm happy that both the accel-based apogee and the baro-based apogee seem to have been pretty much on the money.
In the graph below, you can see the details of when the motor ejection fired and the subsequent tightening of the apogee shock cord. Then later, at the actual apogee, the apogee charge fired which gave the upper section a little kick even though it was on its own, since the charge was still taped to the back end:
Next up, I flew an E75 Vmax (in a cute little 1-grain CTI case), and I removed the motor ejection charge before the flight this time. For this flight, the burn was only about 0.3 seconds and the Gs peaked at about 25. The accel-based and baro-based apogee estimates were still quite good. I put a pretty aggressive low-pass filter on the barometric apogee detection to make sure that transients don't cause a premature apogee detection. That also causes a delay which allows the rocket pass clearly through apogee for a good max altitude estimate. I'm happy to see that the accel-based apogee detection was even closer to apogee than the baro estimate was. Accelerometer inaccuracy has been an issue with the Raven3, and the Raven4 looks like it has improved in this area.
Zooming in on the burn, the lateral sensor shows a little bouncing around of the rocket while it was on the rail, and then as soon as it left the rail (when the accel-based altitude was about 7 feet) it took a little wobble.
A little meta note, since this thread has only gotten a few likes but no comments since I updated it a few days ago....
Everyone, please feel free to make any comments you want to about this product or even semi-related topics on this thread. This thread used to be in the Electronics and Software area, where I normally expect an open dialog with customers, non-customers, the curious, and anyone else. It was moved here (despite my request), but I would like to continue the same open style of dialog here anyway. Thanks for your support, everyone.
Everyone, please feel free to make any comments you want to about this product or even semi-related topics on this thread. This thread used to be in the Electronics and Software area, where I normally expect an open dialog with customers, non-customers, the curious, and anyone else. It was moved here (despite my request), but I would like to continue the same open style of dialog here anyway. Thanks for your support, everyone.
rharshberger
Well-Known Member
It really should have stayed in Software and Electronics as it a development thread not a sales advertisment ( yet).
Just hanging out for some hardware
I'll add to this. I'm really enjoying my Featherweight GPS. As was suggested earlier, I think it would be great to integrate the two, merging the GPS info with the baro and accel data. I'm envisioning a very small, but very powerful and fully featured av-bay.
A really great option would be an onboard magnetic switch. It wouldn't work for every setup but it would greatly simplify installation if the magnetic switch was integral to the unit. I have standardized on them as much as possible but the extra cost and space is a bit of an issue. I know it's late in the game for such an option but maybe for future units.
Also an option without the screw terminals already mounted. In some mounting situations the height of the screw terminals is an issue and I've had to trim the corners. It would be great to be able to make a wiring harness that I could solder to the board and then plug power and charges into that. I realize I can remove the screw terminal myself but it's a bit of challenge.
And a cautionary note: please don't make any major changes to the way the unit works without clearly letting us now. At BALLS a flyer I was with fell prey to a recent software change made to the altimeters he used. Code that was added in as a safety measure ended up causing an unintended deployment and destroyed a very expensive rocket. There was no notification to users so there was no opportunity to check to see if it could be an issue with a particular flight profile.
*EDIT* I see that you have delayed apogee detection with the more aggressive low-pass filter. Can you give us an idea by how much? For heavier rockets that could be a real issue if it starts to pick up significant speed.
Thanks for giving us an opportunity to weigh in here, even if none of these make it in this version hopefully they'll be considered for the next.
Tony
Also an option without the screw terminals already mounted. In some mounting situations the height of the screw terminals is an issue and I've had to trim the corners. It would be great to be able to make a wiring harness that I could solder to the board and then plug power and charges into that. I realize I can remove the screw terminal myself but it's a bit of challenge.
And a cautionary note: please don't make any major changes to the way the unit works without clearly letting us now. At BALLS a flyer I was with fell prey to a recent software change made to the altimeters he used. Code that was added in as a safety measure ended up causing an unintended deployment and destroyed a very expensive rocket. There was no notification to users so there was no opportunity to check to see if it could be an issue with a particular flight profile.
*EDIT* I see that you have delayed apogee detection with the more aggressive low-pass filter. Can you give us an idea by how much? For heavier rockets that could be a real issue if it starts to pick up significant speed.
Thanks for giving us an opportunity to weigh in here, even if none of these make it in this version hopefully they'll be considered for the next.
Tony
Last edited:
- Joined
- Jan 19, 2009
- Messages
- 3,441
- Reaction score
- 1,320
Curious - what is the oscillation in the altitude after apogee? The first case with the E30 shows it bouncing 500' !
The E75 shows only about 200' of bounce/oscillation. Still quite a bit.
What do you think is causing this? I doubt the rocket is physically moving that far that fast and the axial acel data doesn't indicate a lot of activity...
The E75 shows only about 200' of bounce/oscillation. Still quite a bit.
What do you think is causing this? I doubt the rocket is physically moving that far that fast and the axial acel data doesn't indicate a lot of activity...
I think they were pressure transients from the airflow hitting the vent holes or the open end of the airframe (I didn’t have a good seal) as the airframe was tumbling and then swinging under the chute. They do seem a little large for that but part of why it seems that way may be just that these were relatively low flights to start with. Not sure what else it could be. The data is nice and clean until the deployment, so it must be something about the configuration of the rocket after deployment. The velocity at the deployment of the E30 flight was a lot higher due to the premature motor ejection, so that would be consistent with the higher magnitude and frequency.
I’ve definitely been thinking more about that recently. There are two RF microcontroller modules on the tracker. Between them there may be enough spare pins for the continuity measurement, sensor chip selects (I’m not sure yet), and firing signals, but it would add a fair bit of software complexity to split it between the two, especially since Kevin has been working on the Bluetooth module and I have been working on the LoRa module. It’s definitely not happening until the tracker software advanced features are done and the Raven4 is shipping, so it will be a while. I know other folks prefer to have separate units. I’d like to be able to offer the functions separately or combined. But development time is the limiting factor.
The filtering used for the “pressure increasing” check is more aggressive than the filter of the recorded data, but it’s the same for the Raven4 as it has been in previous Raven versions. I agree about not making changes that previous users would need to learn about, unless necessary and well-communicated. I think the main difference that users may notice in the Raven 4 is that the accel-based apogee defection will be more accurate, so that may make accel-based deployment options more useful. But I’ll need to see more flight test results to see what the new limitations are. Next weekend the Raven4 prototype could see some bigger flights in AZ.
SpaceManMat
Space Nut
- Joined
- Dec 20, 2013
- Messages
- 702
- Reaction score
- 86
The only issue with a more accurate accel deployment would be the risk of a back charge going off at the same time as the main. Might want to consider a delay in the default settings for this.
You're right about putting a delay for that backup. The default setting for the accel-based backup apogee detection already does have a 1.5 second delay for that reason.
Tony Lazzaro had a very nice flight today with a prototype Raven4. A K2045 slammed it with up to 96 Gs of thrust, which got it up to 1856 feet/second (Mach 1.65) in under 1 second. The deployments were all nominal, and there were a few interesting bits of data. Here is a zoomed in view of the motor burn:
There were 4 drops in the thrust, maybe from stuff getting ejected from the motor?
The baro sensor recorded a pressure increase during the initial part of the thrust. This can be a response to a high-G event. The column of air inside the av-bay during a 100G burn gets pushed to the back of the rocket, which can measurably affect the measured pressure.
Here's the rest of the ascent:
The effect of a Mach transition is evident in the blue line. The default check for velocity being less than 400 feet/second prevents this transient from causing a premature apogee deployment.
The accel-based apogee detection did pretty well, coming in about 1 second early on a 24.5 second time to apogee. Next is a zoom in on the apogee event:
The baro-based apogee detection allows the apogee pressure readings to take place, and the triggers the apogee deployment. You can see a big positive acceleration from the av-bay in the upper section accelerating forward, and then a negative acceleration when the slack goes out of the deployment harness. Shortly after that, there is a large lateral acceleration without much axial accel, which is likely a re-contact between the two portions of airframe. When I asked Tony about that, he said that in fact there was a mark on both sections that support that theory.
On the descent, you can see the main deployment happening right on time. The continuity voltages for the apogee and 3rd channels start to rise again during the descent. This is pretty common after a charge fires, something about the black powder residue becomes more conductive again after it cools off.
The 3rd and apogee continuity channels are moving closely together because Tony connected both channels to the same charge. The 3rd channel was set to fire at an altitude > 13,500 feet so that if the rocket were accidentally approaching the site FAA waiver, it would fire in time to prevent it from getting there. By connecting them together, then there isn't an un-fired charge hanging around Very nice idea, Tony!
There were 4 drops in the thrust, maybe from stuff getting ejected from the motor?
The baro sensor recorded a pressure increase during the initial part of the thrust. This can be a response to a high-G event. The column of air inside the av-bay during a 100G burn gets pushed to the back of the rocket, which can measurably affect the measured pressure.
Here's the rest of the ascent:
The effect of a Mach transition is evident in the blue line. The default check for velocity being less than 400 feet/second prevents this transient from causing a premature apogee deployment.
The accel-based apogee detection did pretty well, coming in about 1 second early on a 24.5 second time to apogee. Next is a zoom in on the apogee event:
The baro-based apogee detection allows the apogee pressure readings to take place, and the triggers the apogee deployment. You can see a big positive acceleration from the av-bay in the upper section accelerating forward, and then a negative acceleration when the slack goes out of the deployment harness. Shortly after that, there is a large lateral acceleration without much axial accel, which is likely a re-contact between the two portions of airframe. When I asked Tony about that, he said that in fact there was a mark on both sections that support that theory.
On the descent, you can see the main deployment happening right on time. The continuity voltages for the apogee and 3rd channels start to rise again during the descent. This is pretty common after a charge fires, something about the black powder residue becomes more conductive again after it cools off.
The 3rd and apogee continuity channels are moving closely together because Tony connected both channels to the same charge. The 3rd channel was set to fire at an altitude > 13,500 feet so that if the rocket were accidentally approaching the site FAA waiver, it would fire in time to prevent it from getting there. By connecting them together, then there isn't an un-fired charge hanging around Very nice idea, Tony!
Thanks for that explanation, that seems to have happened to a flight at BALLS that caused the altimeter to fire (not a Raven) while the rocket was still under boost. The author of the altimeter software had put in some 'safety' code that tried to determine if the drogue had failed and then it would pop the main. So when the altimeter saw the pressure increase during the early part of the boost it fired both the drogue and main which of course led to a bad outcome. The software author looked at the data and realized what had happened and that he needed to revise his code. He contacted the owners of the affected units to make sure it did not happen again. Good (bad) example of the law of unintended consequences and that there is always more to learn.
Great updates on the new altimeter, looking forward to the final units.
Tony
I can't edit my post above (which is very annoying after such a short time has elapsed) so I have to reply to my own post. I've gotten a clarification on the BALLS flight. The pressure increase early in the flight was substantial and it wasn't a short transient. It was likely due to other causes (other than the air column moving), like a Mach shockwave at the site of the pressure vent. So as always there was more than just a single cause and a typical vent setup would have likely prevented the issue from arising at all. I in no way meant to disparage the software or hardware involved, just that it's impossible to account for all the crazy events that can happen during extreme flight profiles. The flyer of the rocket intends to use the same brand of hardware again next year so he still has full confidence in manufacturer and their products.
Tony
Waiting very very patiently for the release of the Raven4. I have an original Raven that I bought in 2008/9 that continues to put in the work and working 100%. Worked perfectly at MWP 2018 as expected.
Thanks Adrian!!
Thanks Adrian!!
Still hanging out for a Raven4 here as well...
Looks like great results for the testing so far Adrian. Keep up the good work!
Looks like great results for the testing so far Adrian. Keep up the good work!
- Joined
- Nov 12, 2018
- Messages
- 354
- Reaction score
- 210
Adrian,
thanks for the opportunity to try out the new unit, really helped me out on the high g flight! That said, I would agree that really high acceleration is the exception rather than the norm, so the 100g range is more than enough for most things.
I do want to second the interest in a combined gps tracker and altimeter. Maybe not one monolithic unit, but if you could implement an electrical interface between the raven and the gps tracker, then wireless remote arming [no magnets please] and gps based altitude deployments become possibilities. gps based trajectory estimates for upper stage ignition inhibits is another possibility [that would need to be vetted carefully].
I am coming to this topic late [was sooo busy getting the Q finished for BALLS], but one thing that came out of my efforts looking at one of the incidents [at BALLS] is the desire for high side switches on the pyro outputs. While the low side outputs have been working fine for a lot of people, larger rockets that are metal have a lot more opportunity for short circuits, and there having live voltage on the pyro circuits is a big no-no out in the industry. As it stands, I will be implementing a converter board to change the low side signals to high side signals for upcoming projects. It also could become an add-on product for you.
br/
Tony
thanks for the opportunity to try out the new unit, really helped me out on the high g flight! That said, I would agree that really high acceleration is the exception rather than the norm, so the 100g range is more than enough for most things.
I do want to second the interest in a combined gps tracker and altimeter. Maybe not one monolithic unit, but if you could implement an electrical interface between the raven and the gps tracker, then wireless remote arming [no magnets please] and gps based altitude deployments become possibilities. gps based trajectory estimates for upper stage ignition inhibits is another possibility [that would need to be vetted carefully].
I am coming to this topic late [was sooo busy getting the Q finished for BALLS], but one thing that came out of my efforts looking at one of the incidents [at BALLS] is the desire for high side switches on the pyro outputs. While the low side outputs have been working fine for a lot of people, larger rockets that are metal have a lot more opportunity for short circuits, and there having live voltage on the pyro circuits is a big no-no out in the industry. As it stands, I will be implementing a converter board to change the low side signals to high side signals for upcoming projects. It also could become an add-on product for you.
br/
Tony
Hi Adrian,
Just came across this thread. I have communicated my wishes for the ability to hook up an external LED for visual indication. I like to wire a harness to an LED mounted through the airframe... It'd be nice if one of the outputs could be reprogrammable as an auxiliary output, or add a couple of solder pads to allow attachment of a LED (directly, or via harness). I have had two Raven2's and a Raven3 for two+ yrs and still have not flown them because I don't know how to go about visually confirming the status of the altimeters. I believe you said that the audible output has high/low tones, perhaps a bi-color LED could be specified to indicate the differences between hi/lo tones.
I've heard nothing but positive comments about the Raven, but unfortunately due to my deafness, I cannot hear the high/low beeps since they are at frequencies that I have difficulty hearing. Other manufacturers have offered me assistance with changing over my altimeters to LED operation, and one has actually instructed me on how to desolder the piezo and mount a LED, and promised me that the modification would still be covered under warranty. But I digress, I really want the opportunity to use your products, this is seemingly the only barrier to allowing me to use your products independently.
Just came across this thread. I have communicated my wishes for the ability to hook up an external LED for visual indication. I like to wire a harness to an LED mounted through the airframe... It'd be nice if one of the outputs could be reprogrammable as an auxiliary output, or add a couple of solder pads to allow attachment of a LED (directly, or via harness). I have had two Raven2's and a Raven3 for two+ yrs and still have not flown them because I don't know how to go about visually confirming the status of the altimeters. I believe you said that the audible output has high/low tones, perhaps a bi-color LED could be specified to indicate the differences between hi/lo tones.
I've heard nothing but positive comments about the Raven, but unfortunately due to my deafness, I cannot hear the high/low beeps since they are at frequencies that I have difficulty hearing. Other manufacturers have offered me assistance with changing over my altimeters to LED operation, and one has actually instructed me on how to desolder the piezo and mount a LED, and promised me that the modification would still be covered under warranty. But I digress, I really want the opportunity to use your products, this is seemingly the only barrier to allowing me to use your products independently.
Hmm, while I hate to make any extra holes in an airframe I do see how visual confirmation would be useful, especially in some of the configurations I am planning on using. For a two stage one thing I really like is the idea of a magnet on a stick to activate the magnetic switch from a distance. Having the 'beeps' flashed out on an LED would be useful for verifying the altimeter at a distance. Even if it required replacing the piezo it would be useful modification. I read about where a flyer mounted the LED in airframe and then sanded it smooth to match the contour. That would be ideal for this application.
Tony
grouch
Well-Known Member
Adrian, I apologize if this has been addressed somewhere but do you ever intend to make your altimeters Mac friendly? I’m not into computers and I would welcome a plug and play altimeter that is would work on a Mac without a lot of complicated hoops to jump through.
- Joined
- Jan 22, 2013
- Messages
- 379
- Reaction score
- 287
Jarrett, I once started a Java version of the Featherweight Interface Program (jFIP) but was not able to complete it. I did have it so it would download the flight data and graph it but then came the daunting task of trying to replicate the intricate Configuration dialog screen... I will probably revisit it at some time though but for now my time is busy with iPhone and Tracker stuff...
Tony, Thanks for giving us a good test flight and good data.
I agree with the need to have high side switches, and that is why my wiring diagram shows the the altimeter arming switch on the high side. I also recommend adding separate high-side switches in series with high powered airstart ignitors. This allows one to be at the pad, arm their deployments and make sure the altimeter is happy, and only then arm the airstart as the last step before leaving the pad. With this configuration, the really dangerous outputs have 2 high side switches and 1 low side switch. Not coincidentally, NASA requires exactly this configuration for safety-critical pyro functions. 2 High side switches plus 1 low side switch protect against more failure modes than just 2 or even 3 high side switches.
Your wish is my command.
The red LED is tied to the buzzer function, and I have been meaning to make the red and the blue LEDs correspond to the two tones, but I haven't gotten around to it. That should be doable.
Similar threads
