Featherweight Blue Raven Development Thread: Deployment logic

[BDB]

Just “preordered” one tonight. I’m excited to give it a try.

 

[Adrian A]

Status update:

I have programmed, calibrated and tested all the Blue Ravens that have been pre-ordered so far. Now Karen and I are just working through the big shipping backlog. I expect to get caught up tomorrow. 126 units of the first production run of 250 are left. I'm going to kick off the next production run of 750 today or tomorrow.

On the phone app, the simulation capability got a new set of animated graphics to show the state of the rocket during the sim (thrusting, coasting with tilt angle, drogue deployed, main deployed, landed). An phone interface for the accel re-calibration interface is in work. Next is the high rate and low rate data downloads. Then comes the phone interface for remote charge testing, and after that data graphing.

 

[g.pitts]

Just pre-ordered two more. I'm blaming this on peer pressure.

 

[RAM]

I ordered one!! Looks like an awesome altimeter!

 

[Adrian A]

Just pre-ordered two more. I'm blaming this on peer pressure.

I ordered one!! Looks like an awesome altimeter!

Thanks so much! They should be able to go out in the mail today.

 

[Adrian A]

Although this thread has been sort of a catch-all for development status, it's not really the right place for that. I'm trying out a new blog feature in the Weebly website builder I'm using, and I'll see how that goes.

 

[RAM]

Thanks so much! They should be able to go out in the mail today.

Just got mine!!! THANK YOU!!!

 

[Adrian A]

For those just getting their units, the product web page still has current information about the availability of phone interface features.

The default deployment options have gotten by far the most flight testing and simulated testing. While the other options that are accessible through the custom configuration page appear to be working, they have gotten much, much less testing than the default options. So if you want to try out some alternative settings for flight, be sure to test them with the flight simulation first, to make sure that the altimeter is behaving like you expect. Checking new settings with a simulation before your real flight is just good practice and will always be what I recommend even after the Blue Raven is proven with 10s of thousands of flights.

The current iOS build is 140, and that is what I recommend for Android also, even though later builds are available on Android. The next build I make available (probably in the next few days) has underlying changes to the flight data stored in the phone, and it will require deleting the app before installing the new version. If the app seems to be stuck on the splash screen, this is why, and it is remedied by deleting the app before re-installing. The next build will hopefully be the last one that requires deleting the app. T

Updating the user's manual for existing phone features is near the top of my priority list. Hopefully the phone interface is pretty self-explanatory.

 

[Adrian A]

Just got mine!!! THANK YOU!!!

No, thank YOU, and thank everyone who has put your trust in this product and made the early sales such a success so far. I was expecting the first production run of 250 units to last for at least 4-6 months, but 145 have been sold since I opened pre-orders on March 24, not including the 10 beta test units and 10 prototypes. So yeah, I'm getting the next production run kicked off ASAP, while doing my best to make sure that nothing breaks on the software side as we add new features to the phone app.

 

[Fireflash]

Hello,

Is the Raven Blue okay to use with lipos that have the over-current protection boards removed? (1s 3.7v)

 

[Adrian A]

Hello,

Is the Raven Blue okay to use with lipos that have the over-current protection boards removed? (1s 3.7v)

Yes, if they aren't too large. The FETs can handle up to about 20 Amps, similar to the Raven4, so you should stick with batteries that have at least 150 mOhms of internal resistance in case there is a short. 180mAhr or less would be o.k. The Blue Raven only uses about 20 mA, so a few hours on the pad with a 160 mAhr battery is no problem. On my to-do list is to add software for current limiting via PWM so that there isn't any limitation on the batteries used.

 

[FredT]

Adrian-

I have purchased every generation of Ravens over the years for multi-stage flights. I find the Blue Raven intriguing for its ability to measure flight angle for stage ignition safety and remote arming capability via Bluetooth. Because upper stage avionics are often out of reach from ground level, I use remote arming so I don't have to climb a ladder at the pad.

I am configuring a Blue Raven I purchased during pre-sale for an upcoming two-stage flight and rehearsing pre-flight procedures. My typical use-case is to power-on staging avionics while horizontal, raise the vehicle to launch position, then arm pyro channels. During rehearsal I find the channels used for deployment and stage separation are armed at power-up; only pyro channels configured for airstart are unarmed at power-up.

I understand the rationale behind this decision, but unfortunately, it means powering-on a Blue Raven while horizontal will be in violation of TRA and NAR safety codes. A reasonable alternative would be to make the power-up arm state user configurable, with default behavior as it is now.

...Fred

 

[HappyCanuck]

Hi Adrian,

Got my Blue Raven a few days ago, really happy with the purchase. I think it's going to be a great product.

Not sure this is the right place to post, but I have a question regarding the firmware: I tried to update from version 93699c6 (Apr-12-2023) to e1ca8f8; the status shows it completed the update, but upon restart it still shows the original firmware. Am I missing something?

And as per the previous poster, I also think the altimeter should be disarmed by default; if the user wants to change it, he could override this in the settings. This is how the Quantum works, as you probably already know. I tried to disarm all channels, powered down the altimeter and up again (after waiting for the capacitor to discharge), and the altimeter goes back to armed by default. Pretty sure this is a simple fix to implement.

 

[Adrian A]

Adrian-

I have purchased every generation of Ravens over the years for multi-stage flights. I find the Blue Raven intriguing for its ability to measure flight angle for stage ignition safety and remote arming capability via Bluetooth. Because upper stage avionics are often out of reach from ground level, I use remote arming so I don't have to climb a ladder at the pad.

I am configuring a Blue Raven I purchased during pre-sale for an upcoming two-stage flight and rehearsing pre-flight procedures. My typical use-case is to power-on staging avionics while horizontal, raise the vehicle to launch position, then arm pyro channels. During rehearsal I find the channels used for deployment and stage separation are armed at power-up; only pyro channels configured for airstart are unarmed at power-up.

I understand the rationale behind this decision, but unfortunately, it means powering-on a Blue Raven while horizontal will be in violation of TRA and NAR safety codes. A reasonable alternative would be to make the power-up arm state user configurable, with default behavior as it is now.

...Fred

Fred,

The Blue Raven does provide the option for any channel to start out disarmed at power-up or automatically armed at power up (which was true for all previous Ravens), near the bottom of the "custom configuration" screen, which can be used to modify any channel. So what you're asking for is already, there, albeit buried a bit.

However, whether or not the user chooses to have the channel disarmed at power-up, the safety risk posture is essentially the same, because in both cases, the Blue Raven software is already preventing any channel from activating prematurely, by checking for launch detection and burnout detection, (which requires a 40 foot/second change in velocity), in addition to function-specific checks such as apogee detection. If there is a software glitch that can defeat all of the nominal inhibits, then arguably the software check of the manual arming check could also be defeated with the same failure. In NASA safety analysis, software running on one processor counts as one inhibit, meaning that with one failure you need to assume that software will do the worst thing it can do. This is why I always strongly recommend that any HPR airstart should include an interruption of power to the igniter that is completely independent from the altimeter software. Then you can power up the system safely, use the altimeter feedback to verify that the deployments are connected and ready to go, and that the airstart is not connected. Then with the rocket vertical, the last thing before leaving the pad is to arm the airstart channel, and use the altimeter to verify that the airstart is now connected and under control of the altimeter. That's how I fly my airstarts, anyway.

 

[FredT]

Thanks Adrian, I found the setting. Just what I wanted.

 

[Adrian A]

Hi Adrian,

Got my Blue Raven a few days ago, really happy with the purchase. I think it's going to be a great product.

Not sure this is the right place to post, but I have a question regarding the firmware: I tried to update from version 93699c6 (Apr-12-2023) to e1ca8f8; the status shows it completed the update, but upon restart it still shows the original firmware. Am I missing something?

And as per the previous poster, I also think the altimeter should be disarmed by default; if the user wants to change it, he could override this in the settings. This is how the Quantum works, as you probably already know. I tried to disarm all channels, powered down the altimeter and up again (after waiting for the capacitor to discharge), and the altimeter goes back to armed by default. Pretty sure this is a simple fix to implement.

The part of the firmware that does the update is protected from being updated, so once we release the next phone app in the next few days, you should be able to complete the next firmware update. Sorry for the inconvenience. Are you using Android or iOS?

Airstarts and deployment channels are very different in that airstarts are always safer when disarmed, but once the rocket is launched, the rocket is much safer with the deployments armed than disarmed. This is why all of the Ravens and the Blue Raven (with default settings) use liftoff detection and burnout detection to enable the rest of the channel-specific logic to control the output, without adding another arming step that a user might forget. When a Raven or Blue Raven is powered up, it will let you know if charges are connected and it's ready to fly. Power up, check continuity, and walk away from the pad are the only pre-launch steps.

If the Blue Raven deployment channels are disarmed at power-up by default, there would be hundreds if not thousands flights over the next few years that would come in ballistically because the flyer forgot to take the extra step to arm. I would probably have one (or more) of them. In the worst-case scenario, a ballistic HPR rocket can kill a spectator. An accidental deployment charge firing is not only much less severe in consequence, the launch detection and burnout detection have been proven robust at preventing accidental ground deployments. The only ones I'm aware of involving a Raven in the last 9 years have happened because of a miswiring short circuit or something else that electrically bypasses the Raven's output switches, the sort of failure mode that would not be prevented by a manual software arming step.

For the Blue Raven, I added the option to have any of the channels disarmed at power-up, to give airstart flyers some extra piece of mind. But I'm concerned that those flyers will get a false sense of security, by thinking it's equivalent to a truly independent inhibit like an external switch. I'm also concerned that regular dual deployment flyers will set up their chute deployments to be disarmed at power-up and then forget to arm before launch. If I make a change in this area it would be to remove the manual software arming altogether, and keep it like the Ravens have been.

 

[kjhambrick]

Adrian --

All I can say about the Blue Raven is WOW !

I worked with Scott Bartel on the AltAcc nearly 20 years ago now and what I see in the Blue Raven is what I wanted someday for the AltAcc

I have become a BABAR with my two GrandDaughters and I've got the BUG again.

I was a Data Geek back in the day and the Blue Raven is just what I am after to continue my geekery.

I am not sure though, what do I need to fly the device in 24 and 29 mm and larger Rockets ?

I see the Blue Raven -plus- two AV-Bay Deal on the Featherweight site.

Do I also need an external Battery Charger and a Magnet and what else ???

Thanks !

-- kjh

p.s. being a Data Geek, I was wondering about the resolution of the AD Converter for the sensors -- curious but not a deal breaker for me -- I was able to do wonderful things with the 8-bit AD on the AltAcc

 

[FredT]

Adrian-

I don't want to make this a safety discussion, so I'll be brief. I am 100% in agreement with your assessment. I just want to be in compliance with TRA and NAR safety guidelines. From my working days as a software engineer at a US Army weapons development center, I know NASA and DoD policies considering software safety are consistent.

I have elsewhere documented how I mitigate safety concerns in my flight prep procedures with full-up testing. Although I know they would never pass muster in my professional life, I am confident they keep me safe in this particular situation. In the end it comes down to risks you expose to others versus risks you are willing to expose to yourself.

With that said, I'll move on with an app enhancement request.

I like to record altimeter configuration off device. With FIP, I'd take a screen shot of the configuration screen and save that. I can still do that with the app, but it is more difficult to capture the entire custom configuration settings since they do not fit on one screen. I use the Android app and the latest Android versions have a "capture more" function that would allow me to capture the entire configuration window at once. But I think this requires support in the app. I don't know how hard this would be to implement. Something you should pass on to your developer.

...Fred

 

[Adrian A]

Adrian --

All I can say about the Blue Raven is WOW !

I worked with Scott Bartel on the AltAcc nearly 20 years ago now and what I see in the Blue Raven is what I wanted someday for the AltAcc

I have become a BABAR with my two GrandDaughters and I've got the BUG again.

I was a Data Geek back in the day and the Blue Raven is just what I am after to continue my geekery.

I am not sure though, what do I need to fly the device in 24 and 29 mm and larger Rockets ?

There are Featherweight 29mm and 38mm av-bays that include everything you need for a Blue Raven av-bay in a 29mm or 38mm airframe. A magnetically activated switch is built in, to turn the altimeter on at the pad. The 38mm version looks like this:


The threaded rods clamp around a 2.0" long coupler, which is normally glued onto the end of the main chute section of the airframe. The rods also carry the deployment charge current. The 38mm version above, provides access to the apo, main, and 3rd channels from both ends of the av-bay and the 4th channel from the active bulkhead end. The 28mm av-bay has room for 3 rods, and so it carries apo and main to both ends, and 3rd and 4th channels from the active bulkhead end.

I have tentative plans to make a 54mm version for redundant Blue Ravens that would fit inside a 54mm coupler, rather than around it, since you would normally want a 54mm coupler to be more than 2" long.

For 54mm and up, the Power Perch is a popular option. It has the same battery connection and magnetic switch as the other av-bays, but it's designed to be mounted on a traditional sled. It expands the Blue Raven's terminals to provide 2 terminals for each output.

I see the Blue Raven -plus- two AV-Bay Deal on the Featherweight site.

Do I also need an external Battery Charger and a Magnet and what else ???

The 38mm av-bay includes a built-in battery charger (USB mini cable required), but for the other av-bays you will want a Featherweight Dual Battery charger:

This one is small enough that you can permanently install it in your av-bay if you want, or use it separately. It has one USB-micro input connector, and connectors for the two batteries used in Featherweight products, the smaller altimeter battery and the larger tracker battery that can be used at the same time.

Thanks !

-- kjh

p.s. being a Data Geek, I was wondering about the resolution of the AD Converter for the sensors -- curious but not a deal breaker for me -- I was able to do wonderful things with the 8-bit AD on the AltAcc

8-bit sensors require some pretty careful software design to get the most out of them.

The baro sensor has more than 16 bits of resolution, enough for about 1 foot resolution. You can see the altitude change when you hold the Blue Raven at your waist vs over your head. There are two 3-axis accelerometers, each with 16 bit resolution, one with +/- 32 G full scale, and one with +/- 400G full scale. I use and record the 32G range acclerometer except when the high-G range accel measures over 32 Gs. The 3-axis gyros have 16 bits of resolution and a full scale of 2200 deg/sec. The 5 voltage, and 1 current and 1 analog aux measurements, are 12 bits.

Adrian-

I don't want to make this a safety discussion, so I'll be brief. I am 100% in agreement with your assessment. I just want to be in compliance with TRA and NAR safety guidelines. From my working days as a software engineer at a US Army weapons development center, I know NASA and DoD policies considering software safety are consistent.

I have elsewhere documented how I mitigate safety concerns in my flight prep procedures with full-up testing. Although I know they would never pass muster in my professional life, I am confident they keep me safe in this particular situation. In the end it comes down to risks you expose to others versus risks you are willing to expose to yourself.

After thinking about this last night, I agree the manual software arming is a good way to enable safely turning on the altimeter while horizontal and then raising the rocket. The liftoff detection and burnout detection algorithms should be able to deal appropriately with a slow rotation and raise, but stuff happens during a rocket raise maneuver and it's better to not give those algorithms a stressing case.

With that said, I'll move on with an app enhancement request.

I like to record altimeter configuration off device. With FIP, I'd take a screen shot of the configuration screen and save that. I can still do that with the app, but it is more difficult to capture the entire custom configuration settings since they do not fit on one screen. I use the Android app and the latest Android versions have a "capture more" function that would allow me to capture the entire configuration window at once. But I think this requires support in the app. I don't know how hard this would be to implement. Something you should pass on to your developer.

...Fred

Another request that I'm happy to report is already implemented, if I understand correctly what you're looking for. (everyone, I'm not setting up Fred to ask these questions, really! )

On the Deploy screen, at the bottom are buttons for loading or saving files.

These files are formatted for a nice spreadsheet table of all the deployment logic settings and thresholds.
I have attached an example file/ I also pasted it below (where the forum auto-formatted it as a table, nice, but I ran into a character count limit). The time and date at the time you saved the file is part of the file name so you know what the settings were at that particular time. The phone app gives you all the options for sharing those files, like email, Google Drive, OneDrive, etc.

In addition to being able to save off the settings that are on your device now, on every flight the settings that were used during the flight are also saved off to flash and downloaded along with the flight summary data. At the bottom of the flight summary data screen are buttons for saving the configuration, and you have the same file sharing options in that case too. There is another button for reviewing the configuration that was used for that flight inside the app.

 

[Adrian A]

Here's the default deployment settings, pasted as a table:

Hardware_Channel:	Apo_Pri	Apo_Sec	Main_Pri	Main_Sec	3rd_Pri	3rd_Sec	4th_Pri	4th_Sec
Alt_above_pad_<_AGL1	X	X	Check	X	X	X	Check	X
Alt_above_pad_>_AGL2	X	X	X	X	X	X	X	X
Flight_angle_<_FANG1	X	X	X	X	X	X	X	X
Flight_angle_>_FANG2	X	X	X	X	X	X	X	X
Future_Angle_>_FUTANG	X	X	X	X	X	X	X	X
Time_<_TVAL1	X	X	X	X	X	X	X	X
Time_>_TVAL2	X	X	X	X	X	X	X	X
Total_Velocity_<_VEL1	X	X	X	X	Check	Check	X	X
Total_Velocity_>_VEL2	X	X	X	X	X	X	X	X
Baro_velocity_<_BVEL	X	X	X	Check	X	X	X	Check
Burnouts_>_BURNCOUNT	Check	Check	Check	Check	Check	Check	Check	Check
Channel_is_armed	Check	Check	Check	Check	Check	Check	Check	Check
Reserved	X	X	X	X	X	X	X	X
Reserved	X	X	X	X	X	X	X	X
Reserved	X	X	X	X	X	X	X	X
Reserved	X	X	X	X	X	X	X	X
Liftoff	Check	Check	Check	Check	Check	Check	Check	Check
Apogee	Check	Check	Check	Check	X	X	Check	Check
Pressure_Increasing	X	X	Check	X	Check	Check	Check	X
Burnout_Coast	X	X	X	X	X	X	X	X
Apo_Fired	X	X	X	X	X	X	X	X
Main_Fired	X	X	X	X	X	X	X	X
3rd_Fired	X	X	X	X	X	X	X	X
4th_Fired	X	X	X	X	X	X	X	X
Normal_Ascent	X	X	X	X	X	X	X	X
Reserved	X	X	X	X	X	X	X	X
Reserved	X	X	X	X	X	X	X	X
Reserved	X	X	X	X	X	X	X	X
Reserved	X	X	X	X	X	X	X	X
Reserved	X	X	X	X	X	X	X	X
Reserved	X	X	X	X	X	X	X	X
Reserved	X	X	X	X	X	X	X	X
Use_Delay	FALSE	*	FALSE	*	FALSE	*	FALSE	*
Arm_by_default	TRUE	*	TRUE	*	TRUE	*	TRUE	*
Latch_output	FALSE	*	FALSE	*	FALSE	*	FALSE	*
Reserved	FALSE	*	FALSE	*	FALSE	*	FALSE	*
Reserved	FALSE	*	FALSE	*	FALSE	*	FALSE	*
Reserved	FALSE	*	FALSE	*	FALSE	*	FALSE	*
Reserved	FALSE	*	FALSE	*	FALSE	*	FALSE	*
Reserved	FALSE	*	FALSE	*	FALSE	*	FALSE	*
AGL1	700.0	*	700.0	*	700.0	*	500.0	*
AGL2	1000.0	*	1000.0	*	1000.0	*	1000.0	*
VEL1	400.0	*	400.0	*	400.0	*	400.0	*
VEL2	300.0	*	300.0	*	300.0	*	300.0	*
FANG1	15.0	*	15.0	*	15.0	*	15.0	*
FANG2	90.0	*	12.0	*	90.0	*	12.0	*
FUTANG	15.0	*	15.0	*	15.0	*	15.0	*
NOMANG	60.0	*	60.0	*	60.0	*	60.0	*
TVAL1	2.5	*	2.5	*	2.5	*	2.5	*
TVAL2	5.0	*	5.0	*	5.0	*	5.0	*
delay	1.5	*	1.5	*	1.5	*	1.5	*
BVEL1	-200.0	*	-200.0	*	-200.0	*	-200.0	*
BRNCNT	1.0	*	1.0	*	1.0	*	1.0	*

 

[kjhambrick]

Thanks for the info Adrian.

Order Placed.

Another Q: do you expect 24mm AV-Bay Kits soon ?

Thanks again.

-- kjh

 

[Adrian A]

Thanks for the info Adrian.

Order Placed.

Another Q: do you expect 24mm AV-Bay Kits soon ?

Thanks again.

-- kjh

It took about 9 years to sell the last production run of 24mm av-bay kits, so starting a new production run for those is a low priority, at best.

 

[kjhambrick]

NP.

I'll work that out if the need ever arises.

Thanks again Adrian !

 

[HappyCanuck]

The part of the firmware that does the update is protected from being updated, so once we release the next phone app in the next few days, you should be able to complete the next firmware update. Sorry for the inconvenience. Are you using Android or iOS?

Airstarts and deployment channels are very different in that airstarts are always safer when disarmed, but once the rocket is launched, the rocket is much safer with the deployments armed than disarmed. This is why all of the Ravens and the Blue Raven (with default settings) use liftoff detection and burnout detection to enable the rest of the channel-specific logic to control the output, without adding another arming step that a user might forget. When a Raven or Blue Raven is powered up, it will let you know if charges are connected and it's ready to fly. Power up, check continuity, and walk away from the pad are the only pre-launch steps.

If the Blue Raven deployment channels are disarmed at power-up by default, there would be hundreds if not thousands flights over the next few years that would come in ballistically because the flyer forgot to take the extra step to arm. I would probably have one (or more) of them. In the worst-case scenario, a ballistic HPR rocket can kill a spectator. An accidental deployment charge firing is not only much less severe in consequence, the launch detection and burnout detection have been proven robust at preventing accidental ground deployments. The only ones I'm aware of involving a Raven in the last 9 years have happened because of a miswiring short circuit or something else that electrically bypasses the Raven's output switches, the sort of failure mode that would not be prevented by a manual software arming step.

For the Blue Raven, I added the option to have any of the channels disarmed at power-up, to give airstart flyers some extra piece of mind. But I'm concerned that those flyers will get a false sense of security, by thinking it's equivalent to a truly independent inhibit like an external switch. I'm also concerned that regular dual deployment flyers will set up their chute deployments to be disarmed at power-up and then forget to arm before launch. If I make a change in this area it would be to remove the manual software arming altogether, and keep it like the Ravens have been.

I'm using Build 150 on iOS, but it's an old iPhone. I understand that things are still moving quickly and not everything is documented or 100% functional. I just wanted to ensure I wasn't missing something. I'll wait for the next app update and take it from there.

This altimeter will be used for airstarts, so regarding the arming at power-on, if the option exists somewhere in the menus to change it, it works for me.

 

[FredT]

Another request that I'm happy to report is already implemented, if I understand correctly what you're looking for. (everyone, I'm not setting up Fred to ask these questions, really! )

On the Deploy screen, at the bottom are buttons for loading or saving files.
View attachment 577384
These files are formatted for a nice spreadsheet table of all the deployment logic settings and thresholds.
I have attached an example file/ I also pasted it below (where the forum auto-formatted it as a table, nice, but I ran into a character count limit). The time and date at the time you saved the file is part of the file name so you know what the settings were at that particular time. The phone app gives you all the options for sharing those files, like email, Google Drive, OneDrive, etc.

In addition to being able to save off the settings that are on your device now, on every flight the settings that were used during the flight are also saved off to flash and downloaded along with the flight summary data. At the bottom of the flight summary data screen are buttons for saving the configuration, and you have the same file sharing options in that case too. There is another button for reviewing the configuration that was used for that flight inside the app.

Adrian-

You seem to be one step ahead of me. This seems to provide the off-device copy of the configuration data I wanted. It took me a while to understand I needed to remove the .zip extension from the filename to expose the .xlsx extension to open it in Excel. But the data in the file doesn't remotely resemble how I had the BR configured. I assume the file contained strawman data for demonstration purposes. I'm confused with two columns (Pri and Sec) for each pyro channel, please enlighten me.

My main purpose for saving configuration data off-device is to review settings days prior to launch. Careless configuration errors are a chief contributor to my failed staging flights. While all the data seems to be there, it is not the easiest to read for cross checking purposes. I have a few suggestions to improve its readability. Chief among them is in the cases where a setting refers to a parameter, for example the "Alt_above_pad_<_AGL1" row. I like that an X is placed in hardware channels it is not used. But it would be much easier to read if the value of AGL1 was placed in hardware columns where it is used instead of the word "Check". Similarly, "Use_Delay" should show the relevant delay in channels that implement a delay.

While I'm nitpicking, I suggest "Pyros" instead of "Deploy" since deploy suggest recovery functions, but not staging and ignition. Pyros covers it all.

Also, please drop the .zip extension and just go with .xlsx so I don't have to rename the file. Similarly, instead of "BR" use the user-assigned device name. And again use "Pryo" instead of "Deploy". Finally use YYYY-MM-DD format for the time stamp since it sorts better in file listings.

I find it encouraging the app is at the nitpicking stage.

...Fred

 

[Adrian A]

Adrian-

You seem to be one step ahead of me. This seems to provide the off-device copy of the configuration data I wanted. It took me a while to understand I needed to remove the .zip extension from the filename to expose the .xlsx extension to open it in Excel. But the data in the file doesn't remotely resemble how I had the BR configured. I assume the file contained strawman data for demonstration purposes. I'm confused with two columns (Pri and Sec) for each pyro channel, please enlighten me.

My main purpose for saving configuration data off-device is to review settings days prior to launch. Careless configuration errors are a chief contributor to my failed staging flights. While all the data seems to be there, it is not the easiest to read for cross checking purposes. I have a few suggestions to improve its readability. Chief among them is in the cases where a setting refers to a parameter, for example the "Alt_above_pad_<_AGL1" row. I like that an X is placed in hardware channels it is not used. But it would be much easier to read if the value of AGL1 was placed in hardware columns where it is used instead of the word "Check". Similarly, "Use_Delay" should show the relevant delay in channels that implement a delay.

While I'm nitpicking, I suggest "Pyros" instead of "Deploy" since deploy suggest recovery functions, but not staging and ignition. Pyros covers it all.

Also, please drop the .zip extension and just go with .xlsx so I don't have to rename the file. Similarly, instead of "BR" use the user-assigned device name. And again use "Pryo" instead of "Deploy". Finally use YYYY-MM-DD format for the time stamp since it sorts better in file listings.

I find it encouraging the app is at the nitpicking stage.

...Fred

I have never run into the files getting zipped. What method did you use to save them? Normally I just email them to myself, and the .xlsx is preserved.

I see your point about showing the threshold values in the parts of the table where they are used, and I agree that would make it easier to review. Let me think about that whether it would be difficult to implement. Some criteria without thresholds would still get a "Check"

Having a user-assigned device name is a good idea.

See upthread for a discussion of the secondary logic. To recap, each channel will fire if all of the selected criteria in the primary settings are true, OR if all the selected criteria in the secondary settings are true. In the default settings, the channels that take advantage of thisare the main and 4th channels, which are both assumed to be used for a main chute deployment for the default settings. The secondary logic for these channels is that if the Blue Raven detects excessive baro descent rate (faster than 200 feet/second) then the main will deploy early to reduce the chance of a zipper or shredded chute in the event of a failed apogee deployment.

The most recent phone app builds have had accurate file saving and re-loading. There is one more bug we need to take care of before making it generally available.

 

[HappyCanuck]

The part of the firmware that does the update is protected from being updated, so once we release the next phone app in the next few days, you should be able to complete the next firmware update. Sorry for the inconvenience. Are you using Android or iOS?

Airstarts and deployment channels are very different in that airstarts are always safer when disarmed, but once the rocket is launched, the rocket is much safer with the deployments armed than disarmed. This is why all of the Ravens and the Blue Raven (with default settings) use liftoff detection and burnout detection to enable the rest of the channel-specific logic to control the output, without adding another arming step that a user might forget. When a Raven or Blue Raven is powered up, it will let you know if charges are connected and it's ready to fly. Power up, check continuity, and walk away from the pad are the only pre-launch steps.

If the Blue Raven deployment channels are disarmed at power-up by default, there would be hundreds if not thousands flights over the next few years that would come in ballistically because the flyer forgot to take the extra step to arm. I would probably have one (or more) of them. In the worst-case scenario, a ballistic HPR rocket can kill a spectator. An accidental deployment charge firing is not only much less severe in consequence, the launch detection and burnout detection have been proven robust at preventing accidental ground deployments. The only ones I'm aware of involving a Raven in the last 9 years have happened because of a miswiring short circuit or something else that electrically bypasses the Raven's output switches, the sort of failure mode that would not be prevented by a manual software arming step.

For the Blue Raven, I added the option to have any of the channels disarmed at power-up, to give airstart flyers some extra piece of mind. But I'm concerned that those flyers will get a false sense of security, by thinking it's equivalent to a truly independent inhibit like an external switch. I'm also concerned that regular dual deployment flyers will set up their chute deployments to be disarmed at power-up and then forget to arm before launch. If I make a change in this area it would be to remove the manual software arming altogether, and keep it like the Ravens have been.

Deleted.

 

[HappyCanuck]

So I tried to load settings from file, but it doesn't work, even when using a file that has all default settings from the altimeter:

 

[OverTheTop]

While I'm nitpicking, I suggest "Pyros" instead of "Deploy" since deploy suggest recovery functions, but not staging and ignition. Pyros covers it all.

I think "Deploy" is a better moniker for those outputs. It covers both pyro and non-pyro deployments. Motors, valves, solenoids, RC servos, etc can be used, without the need for energetics, for deployment.

 

[FredT]

I have never run into the files getting zipped. What method did you use to save them? Normally I just email them to myself, and the .xlsx is preserved.

I see your point about showing the threshold values in the parts of the table where they are used, and I agree that would make it easier to review. Let me think about that whether it would be difficult to implement. Some criteria without thresholds would still get a "Check"

Having a user-assigned device name is a good idea.

See upthread for a discussion of the secondary logic. To recap, each channel will fire if all of the selected criteria in the primary settings are true, OR if all the selected criteria in the secondary settings are true. In the default settings, the channels that take advantage of thisare the main and 4th channels, which are both assumed to be used for a main chute deployment for the default settings. The secondary logic for these channels is that if the Blue Raven detects excessive baro descent rate (faster than 200 feet/second) then the main will deploy early to reduce the chance of a zipper or shredded chute in the event of a failed apogee deployment.

The most recent phone app builds have had accurate file saving and re-loading. There is one more bug we need to take care of before making it generally available.

I think sharing via OneDrive was responsible for the zip issue. Doesn't happen when I share via Email. Obviously not an app bug.

I have to get my head around the Primary and Secondary criteria. My first reaction was how to prevent unexpected stage ignition from the secondary criteria. Second reaction was how to exploit it to hold-off stage ignition when the trajectory is remarkably vertical. I will read the upthread post.

Looking forward to the next app release.

...Fred