Next-Gen Raven Development Thread

[Adrian A]

The current Raven3 uses an accelerometer that is obsolete, and no similar-footprint parts are available. Since I have to re-spin the design to replace that function, I'm also improving the Raven in a number of other areas that have been an issue over the years. So far, the upgrades are:

1. Use a digital-output accelerometer (This will hopefully make the acceleration measurements more accurate in addition to fixing the availability problem)
2. Increase the deployment channel current up to 25 Amp capability. This should prevent damage for in the case of a short when using a medium-sized lipo battery
3. Larger 4-40 mounting holes, with plated space around the hole rather than circuit traces
4. Acceleration range up to 100 Gs, with the possibility of higher Gs with a software update. Not sure yet if the sensor would be accurate enough at low Gs to enable that yet.
5. Micro-B USB connector now that Mini-B USB cables are not so available
6. Significantly lower power consumption for longer run-time
7. Compatible with higher input voltages (though 4V is still recommended)

The new Raven will have the same features that have made it unique:

• Same small board outline and connector, so all Raven accessories will still work
• Same extensive high-rate data collected and displayed in the Featherweight Interface Program (FIP)
• Same 4 output channels with flexible programming
• Same huge hold-up capacitor that keeps the altimeter running even if the battery is continuously shorted through the outputs for several seconds

I'm posting this thread here to solicit feedback for other improvements that could be made. The groundrules for this revision are:

• No changes to the data sent to/from the FIP, so we don't have to spend time on FIP updates that could be spent on GPS tracker upgrades
• Limited space for new capability in the microcontroller, since I'm sticking with the same one used in the Raven3, again to save development time.
• No changes to board size or connector, to preserve compatibility with existing accessories

Some other things that might be possible if it looks like the cost/benefit is there are pads to connect an external LED, or changes to LED colors, beeper tones. Anything else?

 

[dhbarr]

I used to have a Nokia ringtone that just essentially scaled up in pitch, and with each successve ring it got louder. After it got max loud, the next ring would be quiet again and so forth.

What I lived about that particular ringtone is that everyone could always hear at least part of it. I figured the sometimes-quiet-sometimes-loud probably also saved some battery ( as opposed to continuous loud ).

I've occasionally wished for such a tone to track down rockets ( as opposed to just a single loud tone ) .

 

[cwbullet]

I am happy with the current options for wiring it (AV Bay and the Additive Aerospace product). I would recommend a simple wiring harness to added to the line.

Maybe an electronic listener for old dudes that will count beeps.

 

[jondub]

I am happy with the current options for wiring it (AV Bay and the Additive Aerospace product). I would recommend a simple wiring harness to added to the line.

Maybe an electronic listener for old dudes that will count beeps.

I am 2nding Chuck's wiring harness request. That would help setup a lot. And please don't lower the freq of the buzzer. It is one of the few flight computers this old geezer can actually hear.

What is an "electronic listener"?

 

[rocketsam2016]

I am happy with the current options for wiring it (AV Bay and the Additive Aerospace product). I would recommend a simple wiring harness to added to the line.

Maybe an electronic listener for old dudes that will count beeps.

Since you are changing the USB type already, how about USB c? Likely to be much more future proof

 

[mccordmw]

Built-in wireless arming? I hate drilling out or aligning switch holes.

 

[cwbullet]

Electronic listener: It was a joke, but I often wonder why one had made one. A simple sound counter that could figure the altitude for old guys who have to have someone else count the beeps.

 

[tim cubbedge]

Built-in wireless arming? I hate drilling out or aligning switch holes.

Only problem with wireless is the need for a bigger battery. Why not use the magnetic switch?

 

[Not Quite Nominal]

1: Ability to use tilt as a parameter when firing an output (for staging)

2: App that listens to the beeps and then displays the output in text form

3: Wishful thinking: Have the Raven put out a packet of data, in sound form, every cycle, than can be decoded by the app.

4: Really, really wishful thinking: Ability to communicate with the Raven using the onboard speaker, and an onboard microphone, probably using Bell 103 / 300 baud signalling or a more modern protocol that is more robust in the face of noise. We're all carrying a perfectly good audio modem called a "smartphone". Simpler than wifi, requires no additional hardware on the base station end.

Hold the phone up to the avbay, have it send some packets back and forth, display on app. Obviously very slow and very limited range, but you can't beat the simplicity.

 

[SpaceManMat]

Backwards compatibility with the mounting and the header on the old units would be really nice. A lot of rockets out there will be setup for the old model. It looks like you’ve kept everything the same except making the holes bigger. I’m guessing the old screws will pull through, not sure if a plane washer would be sufficient or an adapter would be required to use the old screws. It might be an idea to offer something like a washer with a flange to adapt down hole size.

 

[cwbullet]

How about and LCD To get data on the field? Not on the board but and add on or plugin LCD.

 

[dshmel]

How about using bluetooth instead of WiFi for arming and programming

 

[mikec]

I think you guys are not getting how constrained this will be -- adding things like tilt sensing is not in the cards as I understand Adrian's ground rules for the design.

Adrian, I hope/assume that the accelerometer will be immune to the offset problem and it'll be possible to use accelerometer apogee more reliably.

That said, if there was a way to insure that very high altitude flights wouldn't overflow the limits of the firmware, and perhaps increase the length of timer delays at the expense of resolution like the special Raven3 firmware, that would help a lot.

Do you have a timeframe for when this will be available?

 

[Rocketjunkie]

Reliability. I usually only fly one altimeter but I will not fly a Raven alone. The Raven is the only altimeter I've used that I'm absolutely sure it was altimeter failure rather than user error or something like ematch failure. I admit, they were version 1 and 2. Both times neither charge fired, the first was so thoroughly destroyed that the silicon chip inside the processor package was busted. The second, version 2, was in a fiberglass rocket and I was able to solder power wires on and connect to my laptop. It never detected liftoff. The first failed on the 23rd flight and the second on the 4th flight.

 

[Adrian A]

posting error

 

[Adrian A]

What I lived about that particular ringtone is that everyone could always hear at least part of it. I figured the sometimes-quiet-sometimes-loud probably also saved some battery ( as opposed to continuous loud ).

I've occasionally wished for such a tone to track down rockets ( as opposed to just a single loud tone ) .

The Raven uses a high tone and a lower tone for its beeps to communicate whether there is continuity on each of its channels before launch, and to communicate zeros during numerical readouts. After landing, the Raven is silent until you pick it up and flip it over. This is because the beeper is a big power hog, and I don't have a way to modulate the volume.

I would recommend a simple wiring harness to added to the line.

Maybe an electronic listener for old dudes that will count beeps.

I am 2nding Chuck's wiring harness request. That would help setup a lot. And please don't lower the freq of the buzzer. It is one of the few flight computers this old geezer can actually hear.

What do you guys have in mind for the harness?

Since you are changing the USB type already, how about USB c? Likely to be much more future proof

I hadn't thought of that. I'm not sure that I can use a USB-C connector the same way I can the USB-B, but I will look into that.

Built-in wireless arming? I hate drilling out or aligning switch holes.

Electronic listener: It was a joke, but I often wonder why one had made one. A simple sound counter that could figure the altitude for old guys who have to have someone else count the beeps.

1: Ability to use tilt as a parameter when firing an output (for staging)

2: App that listens to the beeps and then displays the output in text form

3: Wishful thinking: Have the Raven put out a packet of data, in sound form, every cycle, than can be decoded by the app.

4: Really, really wishful thinking: Ability to communicate with the Raven using the onboard speaker, and an onboard microphone, probably using Bell 103 / 300 baud signalling or a more modern protocol that is more robust in the face of noise. We're all carrying a perfectly good audio modem called a "smartphone". Simpler than wifi, requires no additional hardware on the base station end.

Hold the phone up to the avbay, have it send some packets back and forth, display on app. Obviously very slow and very limited range, but you can't beat the simplicity.

How about and LCD To get data on the field? Not on the board but and add on or plugin LCD.

I like the idea of a phone app that can translate beeps for the hard-of-hearing. I'm not a phone app developer and Kevin, who is, is busy, but I would be happy to work with someone who is interested in that. Making a little dedicated board with an LCD and an a light sensor (the high and low beeps already correspond to 2 different colors of LEDs) is also kind of tempting, but probably not something I have time to develop.

Backwards compatibility with the mounting and the header on the old units would be really nice. A lot of rockets out there will be setup for the old model. It looks like you’ve kept everything the same except making the holes bigger. I’m guessing the old screws will pull through, not sure if a plane washer would be sufficient or an adapter would be required to use the old screws. It might be an idea to offer something like a washer with a flange to adapt down hole size.

The new holes are also offset inward somewhat to allow them to fit. I should do an experiment to see how the new one would fit onto a sled that was drilled for the old one. Some slop will be required, I think.

How about using bluetooth instead of WiFi for arming and programming

The Raven doesn't currently have WiFi. Featherweight Magnetic switches work well for arming without holes. Programming requires a nice display like a laptop or an iPhone to keep the interface easy-to-use. We have thought about using BlueTooth for this in a future altimeter, but it's been kicking our butts on the Featherweight GPS tracker, and Kevin is currently busy for now.

I think you guys are not getting how constrained this will be -- adding things like tilt sensing is not in the cards as I understand Adrian's ground rules for the design.

Adrian, I hope/assume that the accelerometer will be immune to the offset problem and it'll be possible to use accelerometer apogee more reliably.

That said, if there was a way to insure that very high altitude flights wouldn't overflow the limits of the firmware, and perhaps increase the length of timer delays at the expense of resolution like the special Raven3 firmware, that would help a lot.

Do you have a timeframe for when this will be available?

Yes, tilt sensing would require changing the FIP interface and adding more code than this microcontroller has room for. I hope the accel will work better, too. From what I have seen so far, it's not clear yet that the sensor performance will support much improvement if I stick to one accel for the whole dynamic range. Adding a 2nd lower-range accel would be a big help, but I don't think I would have the code space to do that. The timer delays are constrained by the FIP interface, though if that's all that needs to change for the FIP it's probably not a show-stopper. My day job has gotten a lot busier since I started the GPS project, so I hesitate to make any predictions on the release date. A few months at least, I think. This unit doesn't have any user firmware update capability, so it's got to be really well tested before release. Fortunately, a lot of the code that requires flight verification is directly reusable.

Lots of good and interesting feedback, everyone. I appreciate it.

 

[Viperfixr]

Very glad to see the Raven getting a refresh! Suggestions:
- FIP has lots of options, but it would be nice for a simple configurations (presets?) without many variables for new to DD flyers and others that don't want too many options to screw things up (me), and the advanced one for all the bells & whistles
- Some sort of wireless on/off, and/or ground testing and e-match continuity reporting would be awesome (esp ground testing)
- The 25 Amp upgrade will be a great update--will make the battery selection options easier
- Can the new Featherweight GPS be connected for telemetry downlink?
- If not wireless, an on-board magnetic switch that can be put on a battery for a week+ without fear
- Some kind of staging inhibition capability should the flight go too far away from set criteria
- Induction charging perhaps while mounted in a rocket

 

[cvanc]

Slight hijack: I feel your pain on the 'old guys can't hear sh*t' issue. I'm right there with ya. Those beeps are nearly inaudible sometimes.

Long ago I made this; I went a different way to try and solve the same problem. It worked fine, but aiming the microphone directly over a vent hole was a bit fiddly.

https://www.rocketryforum.com/threads/meet-the-wraven-wrangler.70367/

And to get back on track and give some feedback to Adrian: Let me add my voice to those saying unit-to-unit consistency was an issue (I own several). I'm talking about the accelerometer & apogee event inconsistency. It was easy enough to work around this (just use baro sensing for apogee events), but it would be great if you could improve that aspect.

Best wishes on the new model! The Raven 3 remains my favorite flight computer.

 

[cwbullet]

Wiring harness examples from Adept:



This would be an add-on item you could sell. I always loved them on the Adept products. Some make their own. I like being able to buy them sometimes.

 

[mikec]

Limited space for new capability in the microcontroller, since I'm sticking with the same one used in the Raven3, again to save development time.

It is of course unforgivably lame to use the same microcontroller, considering how maxed out it is and given that you're respinning the board anyway -- but I can understand why you would want to do this.

 

[woferry]

I hadn't thought of that. I'm not sure that I can use a USB-C connector the same way I can the USB-B, but I will look into that.

For a USB2-only device application (no SuperSpeed, etc), it's really simple, just replace the connector and put a 5.1kΩ pull-down on each of the CC1/CC2 pins. The USB2 pins on the connector are orientation-neutral (there's a set of pins on each side of the receptacle, you may have to short them on the PCB or they may be shorted in the receptacle) so nothing else is required for orientation support. You *could* get a lot fancier and output extra signals on the SBU pins, etc., but then you have to orient, speak USB-PD to negotiate Alternate Modes, etc. But for a straight-up USB2 device USB-C was designed to be a simple transition.

 

[caveduck]

Hmm I am most in favor of (given the form factor constraints) -

• USB-C - definitely the most future-proof, and as Will notes, the hardware changeover just needs some pulldowns.
• full support for 2S LiPo
• Pre-made wiring harness, small and not bulky.
• #4-40 mounting
• pads to hook up an external LED

and don't care as much about

• 100g accel (not many rockets can do that)
• audio beeper functions

If people want a wifi remote switch, best thing is to hook up an Eggtimer wifi switch. Adding a wifi chip to the raven would be a huge form factor and power draw increase, and it kinda wouldn't be a raven anymore.

Long term, you're going to need a processor with more code space to support proper FIPS api versioning and new features, but I understand that's a big undertaking.

 

[plugger]

Hi Adrian,

I like your plans so far. I'd personally prefer Micro-B USB over USB-C, it's not like the speed differences will be really noticeable given the small nature of .fipa files. Further I've got dozens of Micro USB cables and only a few USB-C.

I'm not in favor of mag switch or wifi switch integration personally, these features can be added on with separate hardware for those who want that capability.

Finally, I prefer to have my flight computers and tracking/telemetry as separate units as long as space allows so for mine I'd prefer you to keep the Raven a "pure" FC.

 

[SpaceManMat]

How about 3 axis acellorometer instead of 2?

 

[Buckeye]

Let me add my voice to those saying unit-to-unit consistency was an issue (I own several). I'm talking about the accelerometer & apogee event inconsistency.

I second this. The current accel can be wonky.

Don't mess with the FIPA! I like all the data, plotting, and export as is.

For wiring harness, I like the PowerPerch concept. I want something to directly receive the ematch wires.

 

[cwbullet]

For wiring harness, I like the PowerPerch concept. I want something to directly receive the ematch wires.

I like this too, but for smaller rockets, a lighter just wire option is helpful.

 

[BryRocket]

The only thing I can currently think of that I have thought I would like is a way to plot/download/analyze negative velocity values or rate of decent via baro data. Seems like I can do that with some other FCs. Perhaps you can do it with the raven and I just missed it. Not super important but I’m always kind of curious to that piece of data. Is that a software deal though?

 

[Adrian A]

Very glad to see the Raven getting a refresh! Suggestions:
- FIP has lots of options, but it would be nice for a simple configurations (presets?) without many variables for new to DD flyers and others that don't want too many options to screw things up (me), and the advanced one for all the bells & whistles

The Raven can be used right out of the box without changing anything for 90% of the applications, and we have preset options that you can select from in the FIP without needing to dig into all the individual flight events.

- Can the new Featherweight GPS be connected for telemetry downlink?
- Some sort of wireless on/off, and/or ground testing and e-match continuity reporting would be awesome (esp ground testing)

Some day I'll have a version that does that, either combined GPS/altimeter on one board, or an altimeter with Bluetooth. But not this version, because of development time constraints.

- The 25 Amp upgrade will be a great update--will make the battery selection options easier
- If not wireless, an on-board magnetic switch that can be put on a battery for a week+ without fear

The Power Perch works that way.

- Some kind of staging inhibition capability should the flight go too far away from set criteria

You can do this already, in a limited way, by checking to make sure that the altitude gets above your threshold before a selected timer expires.

Slight hijack: I feel your pain on the 'old guys can't hear sh*t' issue. I'm right there with ya. Those beeps are nearly inaudible sometimes.

Long ago I made this; I went a different way to try and solve the same problem. It worked fine, but aiming the microphone directly over a vent hole was a bit fiddly.

https://www.rocketryforum.com/threads/meet-the-wraven-wrangler.70367/

That's awesome.

And to get back on track and give some feedback to Adrian: Let me add my voice to those saying unit-to-unit consistency was an issue (I own several). I'm talking about the accelerometer & apogee event inconsistency. It was easy enough to work around this (just use baro sensing for apogee events), but it would be great if you could improve that aspect.

Best wishes on the new model! The Raven 3 remains my favorite flight computer.

Thanks for your support.

Wiring harness examples from Adept:

View attachment 356182 View attachment 356183 View attachment 356181

This would be an add-on item you could sell. I always loved them on the Adept products. Some make their own. I like being able to buy them sometimes.

Thanks for showing that. I see the appeal now. I would need to find a harness subcontractor to make those, since I'm sure I couldn't do it in an affordable way.

It is of course unforgivably lame to use the same microcontroller, considering how maxed out it is and given that you're respinning the board anyway -- but I can understand why you would want to do this.

LOL. I think it's another example of why system engineers make the best EEs. I actually did build a new prototype that was a clean-sheet design with the same ARM microcontroller that I'm using on the Featherweight GPS, but before I got too far into the software I realized that there would be no way for me to find time to finish it any time soon. (Recently my day job has been 60-70 hrs/week and of course there's still more to do on the GPS tracker)

I haven't heard any panic yet so I'm guessing that people haven't noticed yet that the Raven3 is out of stock in the Featherweight store. Yep, it's permanent.

For a USB2-only device application (no SuperSpeed, etc), it's really simple, just replace the connector and put a 5.1kΩ pull-down on each of the CC1/CC2 pins. The USB2 pins on the connector are orientation-neutral (there's a set of pins on each side of the receptacle, you may have to short them on the PCB or they may be shorted in the receptacle) so nothing else is required for orientation support. You *could* get a lot fancier and output extra signals on the SBU pins, etc., but then you have to orient, speak USB-PD to negotiate Alternate Modes, etc. But for a straight-up USB2 device USB-C was designed to be a simple transition.

Thanks for the great info.

Hmm I am most in favor of (given the form factor constraints) -

• USB-C - definitely the most future-proof, and as Will notes, the hardware changeover just needs some pulldowns.
• full support for 2S LiPo
• Pre-made wiring harness, small and not bulky.
• #4-40 mounting
• pads to hook up an external LED

and don't care as much about

• 100g accel (not many rockets can do that)
• audio beeper functions

If people want a wifi remote switch, best thing is to hook up an Eggtimer wifi switch. Adding a wifi chip to the raven would be a huge form factor and power draw increase, and it kinda wouldn't be a raven anymore.

Long term, you're going to need a processor with more code space to support proper FIPS api versioning and new features, but I understand that's a big undertaking.

Thanks for the feedback and the support.

Hi Adrian,

I like your plans so far. I'd personally prefer Micro-B USB over USB-C, it's not like the speed differences will be really noticeable given the small nature of .fipa files. Further I've got dozens of Micro USB cables and only a few USB-C.

I'm not in favor of mag switch or wifi switch integration personally, these features can be added on with separate hardware for those who want that capability.

Finally, I prefer to have my flight computers and tracking/telemetry as separate units as long as space allows so for mine I'd prefer you to keep the Raven a "pure" FC.

Tonight when I was at the grocery store, I did a test to see whether to stick with USB micro-B or go to USB-C. Micro-B is available on the end rack and USB-C isn't (yet) so I'm going to stick with the micro-B for this version.

How about 3 axis acellorometer instead of 2?

It's actually being sensed with the chip I'm using. But it would need FIP interface changes to support it, so I'm going to hold off on that for now.

I second this. The current accel can be wonky.

Don't mess with the FIPA! I like all the data, plotting, and export as is.

For wiring harness, I like the PowerPerch concept. I want something to directly receive the ematch wires.

Thanks for the support.

The only thing I can currently think of that I have thought I would like is a way to plot/download/analyze negative velocity values or rate of decent via baro data. Seems like I can do that with some other FCs. Perhaps you can do it with the raven and I just missed it. Not super important but I’m always kind of curious to that piece of data. Is that a software deal though?

Yes, that would require changing the FIP, which we don't have time for now, but we could do that later and it would be available for all of the FIP versions.

 

[Buckeye]

The only thing I can currently think of that I have thought I would like is a way to plot/download/analyze negative velocity values or rate of decent via baro data. Seems like I can do that with some other FCs. Perhaps you can do it with the raven and I just missed it. Not super important but I’m always kind of curious to that piece of data. Is that a software deal though?

Slight hijack, here. I derive the velocity from the baro altitude by myself, but of course, it is noisy. What is a good reference for filtering/smoothing algorithms?

 

[FredA]

Stop calling channels by functions that are re-assignable.....what I mean by that is just NUMBER the channels like everyone else. Calling a channel "MAIN" and one "APOGEE" gets really confusing when those channels are NOT for that function.
My usual setup is CH1 = Apogee; CH2=Apogee backup (delayed a 1/2 sec); CH3=Low Altitude; CH4=Lower Altitude.
This way I expect the channels to fire in numerical order and the setup is as clear as possible.