Featherweight Blue Raven Development Thread: Deployment logic

The Rocketry Forum

Help Support The Rocketry Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
That's workable for me. Chances are, though, that I'll be on a way outdated iOS, so that might cause issues. I am definitely an outlier when it comes to smartphone use, so definitely don't take my random use case drive development at all.

Looking forward to seeing behind the curtain as the new product develops!

Sandy.
I'm pretty sure that there are many of us who would rather put our $$$ into rocketry instead of buying the latest "bling" cellphones for $1,000+ ... so supporting older iOS would be appreciated.
 
I was thinking of you and I have reserved space for one analog channel at 500 Hz. Normally it would be current but I'd like to make that selectable. There is also a pad on the board for an aux analog input in addition to the channel voltages. Would you prefer to solder a wire onto a pad, or use one of the terminal inputs?

-Adrian
Hi Adrian, that is great news. The 'analog in' pad sounds like the better answer. A 'test point' type terminal, e.g. a single pin header, whatever pitch is convenient, would be even better to keep mods away from the PCB. It could be user-installed to simplify on your end.

Do you plan for anti aliasing filtering? A critically damped 2nd order low pass at 200 Hz would make for a nice 500 Hz acquisition channel.

Still 500 Hz fills memory 5x faster than 100 Hz, so if I had to pick nicely filtered 500 Hz over unfiltered 100 Hz, I would probably go for unfiltered 100 Hz. I would not put 'selectable sample rate' as a need, but if the default is 500 Hz, then it would be a 'nice to have'.

br/
Tony
 
I'm pretty sure that there are many of us who would rather put our $$$ into rocketry instead of buying the latest "bling" cellphones for $1,000+ ... so supporting older iOS would be appreciated.
Agreed. I'm definitely going to make sure that older, inexpensive phones are supported.
 
It does do a lightweight graph on the phone yeah. Its a just a xlsx output of more of the semi-raw values; its somewhat formatted (which is annoying) but gives Time, Pressure, Altitude, Xacc, Yacc, Zacc, TotalAcc values.

As far as email, its just clunky, but that may be more about Android than anything. Its a share option from the app, which then leads you through the share system in Android to get to email, drive, etc. Using drive, if hooked up to google ecosystem, is a bit easier - still goes through the Share option. It would be nice if an app offered integration, so that it was more seamless especially in the field.
The iOS version of the AltimeterThree app's email function is pretty straightforward (or so it seems to me). I've only used the email ability, none of the "socials". I only email the data off my phone if I want to do additional manipulation of the data...such as those overlaid graphs folks may have seen either in the Apogee newsletter or the NAR Member Guidebook. Otherwise the zoomable/scrollable graph, with options to turn on or off the noted data points and the acceleration traces (each axis or combined) is pretty good right there on the phone. It's better on a bigger screen of course, and I will occasionally also download the data to my first-generation iPad Pro.

To get flight data from either AltimeterThree or FlightSketch into their apps on another device one has to download from the altimeter itself, which means either having that device also with you at the field or only flying a given AltimeterThree once so you can download the dataset later. But you can get the data into the app across multiple devices that way. But you need to download to wherever you want it to go before flying the unit again, because for either one, once you say "record" or "arm for flight", the prior data are erased.

Currently the FlightSketch app doesn't allow you to look at prior flights' data in its app at all, but if the data are uploaded to the online log they can be seen and the graphs manipulated some from a web browser, regardless of the device (as long as you have web access, of course). The .csv files can also be downloaded to anything from that web interface. And as I noted before, at least on iOS the flight data are easy to move to other places, as they are individual .csv files accessible through the Files app.
 
The altimeter three at least on Android stores the data in it's internal storage.. even with adb did not find them. Be better if it stored just on the external "card".
 
To get flight data from either AltimeterThree or FlightSketch into their apps on another device one has to download from the altimeter itself, which means either having that device also with you at the field or only flying a given AltimeterThree once so you can download the dataset later. But you can get the data into the app across multiple devices that way. But you need to download to wherever you want it to go before flying the unit again, because for either one, once you say "record" or "arm for flight", the prior data are erased.

Currently the FlightSketch app doesn't allow you to look at prior flights' data in its app at all, but if the data are uploaded to the online log they can be seen and the graphs manipulated some from a web browser, regardless of the device (as long as you have web access, of course). The .csv files can also be downloaded to anything from that web interface. And as I noted before, at least on iOS the flight data are easy to move to other places, as they are individual .csv files accessible through the Files app.

Thanks for all the info. For the Blue Raven mobile app, my plan is to have all the flights that the user has ever downloaded available on the phone via a list, and have a free-form field available for comments, etc., so it can also be used as a flight log.
 
Do you plan for anti aliasing filtering? A critically damped 2nd order low pass at 200 Hz would make for a nice 500 Hz acquisition channel.

Still 500 Hz fills memory 5x faster than 100 Hz, so if I had to pick nicely filtered 500 Hz over unfiltered 100 Hz, I would probably go for unfiltered 100 Hz. I would not put 'selectable sample rate' as a need, but if the default is 500 Hz, then it would be a 'nice to have'.

br/
Tony
There's some oversampling I'm planning on using and I'll see how that goes before adding to the parts count for additional filtering.

My current plan is to have 500 Hz data and 50 Hz data.
 
Thanks for all the info. For the Blue Raven mobile app, my plan is to have all the flights that the user has ever downloaded available on the phone via a list, and have a free-form field available for comments, etc., so it can also be used as a flight log.
That would be similar to the AltimeterThree approach, then. There’s a free-form comment box for each flight there as well. But will one be able to get to the files without going through the app?

Logos both look very cool….
 
Understood on the sample rates. Given the choice between 500Hz and 50Hz, I would select the 500Hz. You might be able to achieve some filtering with the sample & hold capacitor sizing.
 
I'm pretty sure that there are many of us who would rather put our $$$ into rocketry instead of buying the latest "bling" cellphones for $1,000+ ... so supporting older iOS would be appreciated.

I had to finally update my 2013 iPhone to iOS 12.5.5 late last year - it would drop calls constantly. My 2016 iPhone just needed to update to iOS 15.4.1, as I couldn't text pictures anymore. . . Battery life on the 2013 phone is still the same, but the 2016 phone has gone way down, so I have to figure out what forced setting change is screwing that up. If the manufacturers wouldn't pull dumb stuff like that, I would update software, but once I have something that works, I don't want to change.

I do feel bad for developers, like Adrian, though as he needs to address the majority of his market and that means developing for current or 1 generation old hardware at most, not some guy who still uses a 9 year old phone. From my understanding, the phone OEM's actually make it difficult for backward compatibility, so they are forcing his hand or making him run multiple ports and maintaining each of those for bugs as they are discovered. I am 100% for Adrian doing the most logical thing to move the product/software forward for the majority and if the Luddites like myself (and you) who don't want to constantly waste money on stuff we don't need (so we can waste money on what we want) get left behind a while, that's OK. Verizon sent me a letter saying my 2013 phone would be 'expired' at the end of this year and would not connect anymore (maybe 5g related, its only 3g) so I either buy a used phone or go back in the system and spend $10/mo again to pay off a phone over the next 3 years. . .Either way, by the end of the year, sounds like I'll likely be on an iOS or Android version that is more current.

Having said that, if he's going to keep the USB option for the Luddites, I'll likely go that route anyway, as I like a keyboard, even if there isn't a fancy interface.

Thanks again, Adrian, for soliciting input from the user base as you have so often in the past. I like seeing behind the curtain (depending on what the show is. . .).

Sandy.
 
This is the first in a series of development threads in which I'll discuss some design features and tradeoffs of the upcoming Blue Raven altimeter, and give everyone a chance to provide feedback. I'm going to break up the development thread into topics so it will be easier to navigate as the discussion evolves in the future. Disclaimer: This is a behind-the-scenes look that will discuss features that are likely going to change before the final product, and some of which may need to be abandoned or put off.

Background:
The Blue Raven is a ground-up redesign of the popular Featherweight Raven altimeter, built around a much more powerful microcontroller that has Bluetooth capability. The Blue Raven keeps the same small form factor of the Raven, meaning it will fit in 24mm rockets on up, and it will be compatible with all existing Raven av-bay accessories. I'm investing in a top-quality phone app (Apple and Android) to handle all user interfaces for the Blue Raven, including live data, deployment configuration, data download and graphing, etc. Flight testing will take place this spring and summer, and my goal is to have the Blue Raven available for sale early this fall, for about the same price as the current Raven.

Today's topic is the deployment logic. Similar to the Raven, the Blue Raven has 4 output channels. The Raven is very limited in code space and hamstrung by some early design decisions I made, which meant that the 4 output channels had so share some flight event criteria. Below is the setup screen for the default settings all 4 Raven deployment channels. For example, any of the deployment channels had to use the same value for the velocity threshold Vel1 (400 feet/sec in this case):

View attachment 513527

For the Blue Raven, there is enough memory to let each channel have its own independent thresholds. The Blue Raven will also feature full 6-axis inertial sensing (including gyros) and integration that will provide more options and fault tolerance for deployment than were possible before. Here's what I currently have for the flight events that can go into decision to fire a deployment channel. Keep in mind that while all this flexibility is possible, I'll design the user interface to have good default settings so that someone can just buy-and-fly with confidence, and also provide common setups to select from so that nobody is going to have to make a million choices and enter a whole bunch of parameters unless they want to do something really off-the-wall Each all-cap abbreviated word in bold is a threshold that can be set by the user.
  • Barometric altitude above the pad < AGL1
  • Barometric Altitude above the pad < AGL2
  • Flight angle < FANG1
  • Flight angle > FANG2
  • Time since liftoff < TVAL1
  • Time since liftoff > TVAL2
  • Accel-based total velocity < VEL1
  • Accel-based total velocity < VEL2
  • Barometric pressure increasing
  • Barometric-derived upward velocity < BVEL (negative number during descent)
  • Fault-tolerant apogee detected (Two of three sensors indicate apogee: accel-derived vertical velocity < 0, baro pressure increasing, gyro flight angle > 90 degrees)
  • Motor burnout counter > BURNCOUNT
  • 1 second since Apogee channel fired
  • 1 second since Main channel fired
  • 1 second since 3rd channel fired
  • 1 second since 4th channel fired
When all the selected events are true, then the output fires. These set of flight events also opens up the potential for having a set of backup criteria for each channel. For example, the main chute channel can fire with the primary criteria being:
  • Fault tolerant apogee detection took place
  • Barometric altitude above the pad < 700 feet
  • Motor burnout counter >= 1
and then also have backup criteria to fire the main chute:
  • Fault tolerant apogee detection took place
  • 1 second since Apogee channel fired (avoids getting spoofed by pressure spike if the av-bay isn't well sealed)
  • 1 second since 3rd channel fired (3rd channel default would be apogee backup)
  • Barometric-derived upward velocity < -150 feet/second
  • Accel-based total velocity < -150 feet/second
This way, if an apogee charge is undersized or a dud, the main will have a chance to come out before the rocket falls fast enough to shred. I'm currently thinking of making the backup criteria for the main chute part of the default settings. The trick will be to make this easy to understand and use.

Comments are welcome.
I have and love my eggtimer Proton for its four channels ruggedness Bluetooth interface, and I really like the remote ejection charge testing mode, and a lot more. It allowed me to have redundant dual deployment in everything but the electronics.

But I’ve replaced my eggtimer gps systems with your Featherweight gps.

So I’ll be looking forward to seeing how your Blue Raven works.

But just a few suggestions.

I’ve experienced some launch conditions where my Proton Bluetooth signal can’t be picked up by my iPhone. Its quite embarrassing to have your launch computer Bluetooth interface working perfectly at your table, but not at the pad. It might be getting its signal attenuated by aluminum eBay bulkheads in combination with a massive aluminum frame on the launch tower. Carbon fiber laminated airframes could be problematic for signal attenuation too. So having a special fallback Bluetooth-free arming mode like the RRC3+ might be a real launch saver.

Second, there might be a conflict with using your iPhone for the Featherweight gps at the same time because you need to keep the iFIP’s tracker screen live while doing the launch in order to hear the voice call-out of the launch. Doing proper App, Bluetooth, and iPhone screen management might become even more hectic with both a Blue Raven and the Featherweight iFIP.

I already have to find someone to video my launch with a second iPhone if I want to hear the voice call-out from your Featherweight.

Third, have plenty of flight data logger memory in your Blue Raven for scores of flights.

I had and loved my Altimeter3 as a datalogger until I destroyed it in a crash, and I haven’t found a replacement.

Great datalogging on the Blue Raven would make it a must-have in your rocket.

I uploaded all of the Altimeter3 data including the 3-axis accelerometer data to analyze on a spreadsheet. There’s so much that an engineer can tell about each flight by looking at the data.

But good sailing on your new Blue Raven.
 
I’ve experienced some launch conditions where my Proton Bluetooth signal can’t be picked up by my iPhone. Its quite embarrassing to have your launch computer Bluetooth interface working perfectly at your table, but not at the pad. It might be getting its signal attenuated by aluminum eBay bulkheads in combination with a massive aluminum frame on the launch tower. Carbon fiber laminated airframes could be problematic for signal attenuation too. So having a special fallback Bluetooth-free arming mode like the RRC3+ might be a real launch saver.
Dan, thanks for providing these valuable insights.

The default settings for the deployment channels will be to have them armed at power-up. Defaults for airstarts will be manual arming. When you were having a problem was that when you were next to the rocket at the pads, or back at the flight line? For the larger range distances, I could see losing contact back at the flight line, but that should be o.k. as long as everything checked out while you were next to it.

Second, there might be a conflict with using your iPhone for the Featherweight gps at the same time because you need to keep the iFIP’s tracker screen live while doing the launch in order to hear the voice call-out of the launch. Doing proper App, Bluetooth, and iPhone screen management might become even more hectic with both a Blue Raven and the Featherweight iFIP.

In the near-term there will be a period where the FIP and the Blue Raven app are separate, but my plan is to re-do the tracking as part of the new app. Once you use your phone to make sure everything checks out while you're at the pad, it seems like you could just watch the tracker app from there without needing to go back to it.
I already have to find someone to video my launch with a second iPhone if I want to hear the voice call-out from your Featherweight.
Have you tried the built-in iPhone screen video recording feature? It works in the background with whatever screen you're on.

I'm starting a new thread about plans for the Blue Raven's data logging capabilities, and I'll respond to your data suggestion there.
 
[thread drift]
Verizon sent me a letter saying my 2013 phone would be 'expired' at the end of this year and would not connect anymore (maybe 5g related, its only 3g) ...
It's the 3g. All the major networks are shutting down their 3g services. This has left me without the ability to access my Kia Soul EV's telematics abilities (the modem in the car is 3g, Kia has no plans for an upgrade) and made me go through a really painful upgrade of my ADT home security system (as the Pulse system had a 3g communications backup built in, but the new system is much better, now that I have it).
[/thread drift]
 
Thanks for the kind response. I hope I wasn’t being too forward with my suggestions. Before retiring I was in similar situations as a product developer when users became “too helpful” in making suggestions as though it was their product instead of mine. I certainly wasn’t wanting to be like that.

When you were having a problem was that when you were next to the rocket
at the pads, or back at the flight line?
I was next to the rocket after loading it onto the horizontal launch pad and moving it to vertical so that I could arm it. (In addition I mistakenly said that the Proton had Bluetooth; it actually has WiFi.) I had tested the WiFi communications while the rocket was at my table.

Additionally, I’m quite experienced with the Proton. I first used it for my L2 in June 2020 as an “almost” fully redundant dual deployment recovery system, and its been my “go to” recovery system before starting to use RRC3+/RRC2 controllers on my new Mad Cow SDX3 for having a simpler on/off redundant dual deployment recovery.

Once you use your phone to make sure everything checks out while you're at the pad, it seems like you could just watch the tracker app from there without needing to go back to it.

I’m sure this will work, and I was planning on doing this. My only point was with all the things that need to be minded for a successful flight, every additional thing raises the likelihood of missing something critical and having a problem.

Have you tried the built-in iPhone screen video recording feature? It works in the background with whatever screen you're on.
I finally got this to work after trying on four launches so that I could record the iFIP tracker screen with voice feedback from the launch tracking the flight. Several people were standing by, including two “Kate” users, and everyone was impressed.

But the point I was making was that the iFIP “voice” feature only seems to work when the iFIP tracker screen is actively being displayed, and this prevents me from hearing and recording the voice while I’m using the iPhone to take a video of the launch.
 
I was next to the rocket after loading it onto the horizontal launch pad and moving it to vertical so that I could arm it. (In addition I mistakenly said that the Proton had Bluetooth; it actually has WiFi.) I had tested the WiFi communications while the rocket was at my table.
Thanks for the info. I have been thinking about the fact that the Bluetooth range may not extend out to the flight line, and I want to make sure that that won't unduly concern anyone. I'll want the indication that bluetooth connection is lost to be visible but not alarming, and still show the status from the last time BLE was connected.

Along these lines, I have been thinking about how the beeper should work. I could have the beeper act like the current one on the Raven does, where at power-up, the beeper tells you the battery voltage and then whether there is voltage on each deployment channel. To make the system functional in the event of a lost phone or Bluetooth problem, those beeps would need to be there. But maybe while the Bluetooth connection is active, the beeping could be turned off, either automatically or manually.

But the point I was making was that the iFIP “voice” feature only seems to work when the iFIP tracker screen is actively being displayed, and this prevents me from hearing and recording the voice while I’m using the iPhone to take a video of the launch.
Yes, that's something I would like to fix when the tracker functionality is migrated to the new app later this year.
 
I have and love my eggtimer Proton for its four channels ruggedness Bluetooth interface, and I really like the remote ejection charge testing mode, and a lot more. It allowed me to have redundant dual deployment in everything but the electronics.

But I’ve replaced my eggtimer gps systems with your Featherweight gps.

So I’ll be looking forward to seeing how your Blue Raven works.

But just a few suggestions.

I’ve experienced some launch conditions where my Proton Bluetooth signal can’t be picked up by my iPhone. Its quite embarrassing to have your launch computer Bluetooth interface working perfectly at your table, but not at the pad. It might be getting its signal attenuated by aluminum eBay bulkheads in combination with a massive aluminum frame on the launch tower. Carbon fiber laminated airframes could be problematic for signal attenuation too. So having a special fallback Bluetooth-free arming mode like the RRC3+ might be a real launch saver.

Second, there might be a conflict with using your iPhone for the Featherweight gps at the same time because you need to keep the iFIP’s tracker screen live while doing the launch in order to hear the voice call-out of the launch. Doing proper App, Bluetooth, and iPhone screen management might become even more hectic with both a Blue Raven and the Featherweight iFIP.

I already have to find someone to video my launch with a second iPhone if I want to hear the voice call-out from your Featherweight.

Third, have plenty of flight data logger memory in your Blue Raven for scores of flights.

I had and loved my Altimeter3 as a datalogger until I destroyed it in a crash, and I haven’t found a replacement.

Great datalogging on the Blue Raven would make it a must-have in your rocket.

I uploaded all of the Altimeter3 data including the 3-axis accelerometer data to analyze on a spreadsheet. There’s so much that an engineer can tell about each flight by looking at the data.

But good sailing on your new Blue Raven.

I have two Protons. I believe they use WiFi, not Bluetooth. And they have 6 pyro channels, not 4.
 
I have two Protons. I believe they use WiFi, not Bluetooth. And they have 6 pyro channels, not 4.

You are correct on all counts. But I’ve only used 4 as an almost redundant dual deployment recovery system, so I totally forgot about the other two.

I was attempting to correct my Bluetooth/WiFi mistake in a response to Adrian while answering his other questions, but got interrupted and the whole response got lost in the “virtual ether” while in the “preview mode”.

The Proton has been my “go to” controller since doing my L2 with a “nearly redundant dual deployment recovery system“ on a modified Zephyr in June, 2020.

I really like being able to easily perform ejection charge testing with either the Proton or the Quantum, but sometimes the seconds countdown feature doesn’t work correctly the first time and it fires the charge when you start it. This is a real nuisance if you’re trying to video the test.

Because I like the Proton and really like the Featherweight, I’m nearly certain that I’ll buy the Blue Raven when it comes out if its as good as its looking now.
 
totally random, off topic suggestion. It would be useful for tinkerers if there was a way to hook into the events or datastream on a Raven. For example, a connector where you can hook into an i2c bus or something and get notified when a flight event occurs. In one of my hundreds of half-done projects, i want to fly my own separate microcontroller but i want to tell it when "motor burnout" occurred vs trying to detect it myself. The Raven, AltusMetrum's stuff, and others have this all figured out really well. It would be useful to use those devices for flight events vs redoing it from scratch in your own code.
 
totally random, off topic suggestion. It would be useful for tinkerers if there was a way to hook into the events or datastream on a Raven. For example, a connector where you can hook into an i2c bus or something and get notified when a flight event occurs. In one of my hundreds of half-done projects, i want to fly my own separate microcontroller but i want to tell it when "motor burnout" occurred vs trying to detect it myself. The Raven, AltusMetrum's stuff, and others have this all figured out really well. It would be useful to use those devices for flight events vs redoing it from scratch in your own code.
Maybe you can selectively map flight events to pyro to outputs if that is an easy firmware/hardware solution?

It's already possible to use the deployment outputs as discrete indicators with the Raven4 and will be with the Blue Raven as well. You can use an otherwise unused output channel to indicate when any of the deployment condition checks are true by just selecting that check within the FIP.
 
It's already possible to use the deployment outputs as discrete indicators with the Raven4 and will be with the Blue Raven as well. You can use an otherwise unused output channel to indicate when any of the deployment condition checks are true by just selecting that check within the FIP.
do you mean connecting a pyro output to like an ADC input on another microcontroller? I thought there were issues with continuity checking and needing like an optoisolator between the two etc
 
do you mean connecting a pyro output to like an ADC input on another microcontroller? I thought there were issues with continuity checking and needing like an optoisolator between the two etc
The deployment outputs are open-drain, meaning that when they get turned on, they just connect the terminal to ground. So whatever logic levels you're using (up to 20V), you can connect the signal with a pull-up resistor to your digital voltage rail and to the Raven output, and the Raven will just ground it when the logic conditions are true.
 
Kevin and I were wondering if the Blue Raven was going to be tested in the traditional Blue Ninja?
That would be appropriate, but sadly no, that rocket has retired to the great beyond. But Larry Haynes has lent a 54mm FG rocket with a big payload bay which is saving me a bunch of time. And I will fly it with Raven 4 and Featherweight GPS tracker for post-flight analysis.
 
Yesterday I ran out of time and energy to get done what I needed to before today's launch, so today I'll be coding rather than flying. I'm thankful to have so many good clubs around so I won't need to wait a month.
 
That would be appropriate, but sadly no, that rocket has retired to the great beyond. But Larry Haynes has lent a 54mm FG rocket with a big payload bay which is saving me a bunch of time. And I will fly it with Raven 4 and Featherweight GPS tracker for post-flight analysis.

I might have a Blue Ninja if that would help - or an Estes Tomahawk which might have a usable Av Bay... but I agree a 54 mm with more payload space would be good for multiple electronics...!
 
Back
Top