Featherweight Blue Raven Development Thread: Ground tests

The Rocketry Forum

Help Support The Rocketry Forum:

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

Adrian A

Well-Known Member
TRF Sponsor
TRF Supporter
Joined
Jan 21, 2009
Messages
3,185
Reaction score
2,912
Location
Lakewood, CO
Although there are a number of minor bugs we're cleaning up and the automatic download of time series data is not available yet, I want to look ahead to the last major phone interface feature to be added, which is ground testing of deployment charges.

For people who have used a remote ground test feature for deployment charge sizing with other wireless devices, what features did you like and what would you like to see done differently. Here's my own wish list:

  • Record a short slow-motion video
  • One button starts the countdown and cancels it
  • Show live continuity voltages for each channel
  • Use on-board sensors to record data during the firing (accelerometer, baro sensor for pressure leak, etc.) as if it were a short flight
  • Add an easy way for the user to enter the charge size that was used
  • Keep the slo-mo video, recorded data, and associated charge size together for future reference.
 
Can you measure the main battery voltage when doing the testing, and record the minimum as the charge is fired? That way if you have a marginal battery supply and the pyros load it to the point of being near a brownout situation there will be some indication. Bonus for putting a limit detection and warning of possible outcomes, rather than just a voltage number. Maybe a warning to check the number and confirm if the system is as the user intends it to be.
 
Can you measure the main battery voltage when doing the testing, and record the minimum as the charge is fired? That way if you have a marginal battery supply and the pyros load it to the point of being near a brownout situation there will be some indication. Bonus for putting a limit detection and warning of possible outcomes, rather than just a voltage number. Maybe a warning to check the number and confirm if the system is as the user intends it to be.
Yes, the battery voltage and current are part of the normal recorded data, and the battery minimum voltage is already part of the standard flight summary information.
 
Adrian --

Studying the Blue Raven Manual and only two Qs so far.

Q1: Are the USB Serial-Mode Commands case-sensitive ?

If not, all the commands except the LED Command on page 17 are lower case

Q2: Is the LED Command actually upper case ?

The reason I ask is because I am gathering the defines to write a q&d UNIX / Linux Program for the Blue Raven.

According to the Linux Driver Info I've gathered, the STMicro Virtual Com Port (VCP) drivers are already supported by Linux so we shall see.

Thanks again !

-- kjh
 
Adrian --

Studying the Blue Raven Manual and only two Qs so far.

Q1: Are the USB Serial-Mode Commands case-sensitive ?

If not, all the commands except the LED Command on page 17 are lower case

Q2: Is the LED Command actually upper case ?

The reason I ask is because I am gathering the defines to write a q&d UNIX / Linux Program for the Blue Raven.

According to the Linux Driver Info I've gathered, the STMicro Virtual Com Port (VCP) drivers are already supported by Linux so we shall see.

Thanks again !

-- kjh
Yes, they are case sensitive. I'm not known for consistency, but if you're looking for a rationale, I used lower case except for acronyms.
 
Thanks for the info Adrian.

UPPER CASE ACRONYMS makes sense to me.

And as a software developer myself, I've learned to not toss any stones :)

I've got a lot to learn but I'll play with the Blue Raven on Linux after I've got a little experience with my Samsung Phone and the Windows App.

-- kjh
 
Although there are a number of minor bugs we're cleaning up and the automatic download of time series data is not available yet, I want to look ahead to the last major phone interface feature to be added, which is ground testing of deployment charges.

For people who have used a remote ground test feature for deployment charge sizing with other wireless devices, what features did you like and what would you like to see done differently. Here's my own wish list:

  • Record a short slow-motion video
  • One button starts the countdown and cancels it
  • Show live continuity voltages for each channel
  • Use on-board sensors to record data during the firing (accelerometer, baro sensor for pressure leak, etc.) as if it were a short flight
  • Add an easy way for the user to enter the charge size that was used
  • Keep the slo-mo video, recorded data, and associated charge size together for future reference.
All of this sounds FANTASTIC!
 
Hi Adrian,

This all sounds really good, looking forward to using it. What's your timeline for this next release?
 
Well done, Adrian. Been looking things over on the website and I am really liking what I am seeing. Might have to add a new Raven to the arsenal. I have an original and a 4, might be time. You and Cris are providing our community with such amazing hardware/software devices. I thank the both of you for really taking our hobby to the next level.
 
Woo Hoo !

What a gadget, Adrian !

The more I play with it the better it gets.

I think I'll need another one because now that it is mounted in the 38 mm AV-Bay, I hate to remove it !

And OBTW ...

I can see the the Blue Raven USB-Serial Port on my Linux Laptop:
Code:
# plugged in the micro USB:
[Tue May  2 17:23:57 2023] usb 1-1: new full-speed USB device number 13 using xhci_hcd
[Tue May  2 17:23:57 2023] usb 1-1: New USB device found, idVendor=0483, idProduct=5740, bcdDevice= 2.00
[Tue May  2 17:23:57 2023] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[Tue May  2 17:23:57 2023] usb 1-1: Product: STM32 Virtual ComPort
[Tue May  2 17:23:57 2023] usb 1-1: Manufacturer: STMicroelectronics
[Tue May  2 17:23:57 2023] usb 1-1: SerialNumber: 206135794256
[Tue May  2 17:23:57 2023] cdc_acm 1-1:1.0: ttyACM0: USB ACM device
[Tue May  2 17:23:57 2023] usbcore: registered new interface driver cdc_acm
[Tue May  2 17:23:57 2023] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters

# unplugged:
[Tue May  2 17:28:20 2023] usb 1-1: USB disconnect, device number 13

# plugged in again:
[Tue May  2 17:29:29 2023] usb 1-1: new full-speed USB device number 14 using xhci_hcd
[Tue May  2 17:29:29 2023] usb 1-1: New USB device found, idVendor=0483, idProduct=5740, bcdDevice= 2.00
[Tue May  2 17:29:29 2023] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[Tue May  2 17:29:29 2023] usb 1-1: Product: STM32 Virtual ComPort
[Tue May  2 17:29:29 2023] usb 1-1: Manufacturer: STMicroelectronics
[Tue May  2 17:29:29 2023] usb 1-1: SerialNumber: 206135794256
[Tue May  2 17:29:29 2023] cdc_acm 1-1:1.0: ttyACM0: USB ACM device

Thanks again Adrian.

-- kjh

p.s. II'll play with the serial commands this weekend after the Saturday AARG Launch ( :) I don't want to lose my 'real job' because I am so distracted by rocketry :) )
 
Hi Adrian,

This all sounds really good, looking forward to using it. What's your timeline for this next release?
Hopefully tomorrow, if regression testing is successful. It will have higher Bluetooth transmit power, and a number of bug fixes. No download of the time-series flight data is available to the phone yet; we have been focused on getting a clean baseline for people to use before completing the work on the downloads.

One change I'm making to the default deployments is for the main chute deployments. Advance warning: the following explanation is going to get pretty deeply into the details. The challenge of the main chute deployment logic is getting it to ignore transient pressure spikes that often happen when the apogee charge fires due to imperfect av-bay sealing. The previous method I used for this is to check for the apogee channel to have been fired, which becomes true 1.50 seconds after the apogee event, at which point a transient would be done. This approach unfortunately depends on the apo channel being used for the apogee charge, which will usually be the case, but I'd prefer not to count on that. If someone were to use the apo channel for some other function, then it would be bad for that choice to cause a problem for the main chute deployment.

Over the last few months I have been adjusting the filtering and persistence check for the barometric velocity, which I use to determine if the main chute should be deployed early in the event of an apogee deployment failure. This is implemented in the default settings, using the secondary criteria for the main chute. The baro velocity check needs to ignore pressure transients from apogee pressure leaks, or sunlight hitting the baro sensor, or other transients, all of which I have experienced in my own flights. I applied the same filtering methods to the "pressure increasing" flight event, so now it is also ignores transient pressure measurements. This means that I can use it as one of the default criteria for deploying the main chute. Now the main chute logic is independent from whatever function the apo channel is being used for.

While I'm here, a quick status update. All the Blue Ravens from the first production run of 250, plus 8 of the first 10 units from the second production run (750 units) are sold. The next 100 units from the 2nd production run will be available sometime this week, possibly as soon as tomorrow. The rest of the production run (640 units) will be available later this month.
 
Just saw that the latest build is released, I’ll start fiddling with it. BTW this is great timing, I was planning on doing some ground tests soon. It's nice too see how quickly you're developing this.

Thanks Adrian.
 
Thanks for the head's up HappyCanuck

Updating my BlRv SN 0236 now ... and done !

Thanks for the update Adrian !

-- kjh

EDIT: I believe I actually down-graded the firmware.

The previous and current revision ids are:

Code:
Prev:  93699c6 - Apr 21 2023
Curr:  e1ca8f8 - Apr 12 2023

HappyCanuck ... how did you find the latest build ?
 
Last edited:
Hopefully tomorrow, if regression testing is successful. It will have higher Bluetooth transmit power, and a number of bug fixes. No download of the time-series flight data is available to the phone yet; we have been focused on getting a clean baseline for people to use before completing the work on the downloads.

One change I'm making to the default deployments is for the main chute deployments. Advance warning: the following explanation is going to get pretty deeply into the details. The challenge of the main chute deployment logic is getting it to ignore transient pressure spikes that often happen when the apogee charge fires due to imperfect av-bay sealing. The previous method I used for this is to check for the apogee channel to have been fired, which becomes true 1.50 seconds after the apogee event, at which point a transient would be done. This approach unfortunately depends on the apo channel being used for the apogee charge, which will usually be the case, but I'd prefer not to count on that. If someone were to use the apo channel for some other function, then it would be bad for that choice to cause a problem for the main chute deployment.

Over the last few months I have been adjusting the filtering and persistence check for the barometric velocity, which I use to determine if the main chute should be deployed early in the event of an apogee deployment failure. This is implemented in the default settings, using the secondary criteria for the main chute. The baro velocity check needs to ignore pressure transients from apogee pressure leaks, or sunlight hitting the baro sensor, or other transients, all of which I have experienced in my own flights. I applied the same filtering methods to the "pressure increasing" flight event, so now it is also ignores transient pressure measurements. This means that I can use it as one of the default criteria for deploying the main chute. Now the main chute logic is independent from whatever function the apo channel is being used for.

While I'm here, a quick status update. All the Blue Ravens from the first production run of 250, plus 8 of the first 10 units from the second production run (750 units) are sold. The next 100 units from the 2nd production run will be available sometime this week, possibly as soon as tomorrow. The rest of the production run (640 units) will be available later this month.
Adrian,

Would we still have the option to prevent a charge from firing before 1.5 seconds from the previous event or are you completely deleting that feature? Personally I would really like if that was still an option.
 
Adrian,

Would we still have the option to prevent a charge from firing before 1.5 seconds from the previous event or are you completely deleting that feature? Personally I would really like if that was still an option.
Yes, it's still an option; I'm just moving it out of the default settings.
 
Thanks for the head's up HappyCanuck

Updating my BlRv SN 0236 now ... and done !

Thanks for the update Adrian !

-- kjh

EDIT: I believe I actually down-graded the firmware.

The previous and current revision ids are:

Code:
Prev:  93699c6 - Apr 21 2023
Curr:  e1ca8f8 - Apr 12 2023

HappyCanuck ... how did you find the latest build ?
When you select the over-the-air update of the firmware, it gives you an option to select BLERaven.bin, which is the default latest firmware and intended to be used with that build, or you can select an alternate file. The alternate file is just there as a hook to keep the door open for a custom build or something like that in the future. The new build 167 should have b15fbbd as the built-in default OTA option. It's currently available only on iOS, because there is a weird Android-only problem with the sim initialization that we are still working out.
 
Just saw that the latest build is released, I’ll start fiddling with it. BTW this is great timing, I was planning on doing some ground tests soon. It's nice too see how quickly you're developing this.

Thanks Adrian.
Thanks for your support. The pedal is to the metal at least until we get the time series data downloads, graphs, and ground test interfaces done.

The new ground test capability is probably a few weeks out, and will come after the data downloads. I'd like to have the downloads working for my own flights this weekend, but I have a bunch of new Blue Ravens to prep to get back into stock, plus my own rocket prep and a tower upgrade to get done before this weekend, so chances it will happen this week are dwindling.
 
Thanks for the head's up HappyCanuck

Updating my BlRv SN 0236 now ... and done !

Thanks for the update Adrian !

-- kjh

EDIT: I believe I actually down-graded the firmware.

The previous and current revision ids are:

Code:
Prev:  93699c6 - Apr 21 2023
Curr:  e1ca8f8 - Apr 12 2023

HappyCanuck ... how did you find the latest build ?
I really like it. The app is functional enough that I can do pretty much all the setups and testing I need. The latest firmware build I have now is b15fdfb, but it reboots by showing e361a01. Not sure what is going on, but it works...

I used Christmas lights to test the channels using the simulation. One small glitch I noticed is the vertical velocity, which gradually keeps increasing throughout the flight. The simulation works fine otherwise and all channels deploy at their correct settings.

I can disarm any channel by using the Custom Configuration setting for each channel; Adrian has made it fairly fool-proof as you really need to dig into the menus to have them disarmed on start-up. And much to my chagrin, I've core sampled a few virtual rockets already by not following my checklist and launching with all channels disarmed. You were right, Adrian...

One thing that was not obvious to me at first is that the serial USB interface (I use RealTerm) is still needed to program, verify and download data to/from the Blue Raven. This is all explained in the manual on his website. The app looks really slick and finished so I had assumed that nothing else was needed. Using the USB interface is not a big deal for me at the moment, especially knowing that it's only temporary.
 

Attachments

  • BR programing.png
    BR programing.png
    80.8 KB · Views: 0
When you select the over-the-air update of the firmware, it gives you an option to select BLERaven.bin, which is the default latest firmware and intended to be used with that build, or you can select an alternate file. The alternate file is just there as a hook to keep the door open for a custom build or something like that in the future. The new build 167 should have b15fbbd as the built-in default OTA option. It's currently available only on iOS, because there is a weird Android-only problem with the sim initialization that we are still ...

Adrian --

Yes, I loaded the BLERaven.bin file.

It sounds like IOS -vs- Android explains the apparent downgrade ( I have an Android phone )

No worries, I will stand by.

-- kjh
 
Last edited:
Adrian --

Yes, I loaded the BLERaven.bin file.

It sounds like IOS -vs- Android explains the apparent downgrade ( I have an Android phone )

No worries, I will stand by.

-- kjh
In case you're curious, the problem we're working through on the Android version is that when the simulation is started, the Android phone only sends across 20 of the needed 27 bytes that describe the simulation setup. My developer and I have been digging into this for the last couple of days.
 
Thanks for the Android Update Adrian.

I received an email last night: "Blue Raven 1.0.0 (168) for Android is ready to test"

I immediately installed the new firmware and ran a quick Sim using the factory default settings.

Reviewing your posts and the manual and testing ...

Thank you !

-- kjh

EDIT: oops. I wrote this around 04:00 CDT and never hit post.

more to come.
 
Edit: I reloaded the same firmware ( 7d4488f - 05/04/2023 09:50:51 ) and I've got a green Accel 16g again.

Will follow up.

Adrian --

I Calibrated the Accelerometer from the Phone App and it prompted me for the three-axis orientations ( new feature ).

I let it run until the Battery Level was 3.86 Volts and Shut Down the Blue Raven.

I charged the Battery ( 30-min for a Green Light )

Rebooted the Blue Raven and then connected via Bluetooth from my Android Phone.

Boot up beeps were normal ( long, short, 4-beeps )

Accel 16g is now offline ( Pink Background ).

Accel 400g and Gyro are Green

Tried to look at the Flights and all I saw was NaN Error after selecting a Simulated Flight.

...

Shutdown the Blue Raven and did a Force-Stop on the Android App.

Restarted the Blue Raven and the Android App.

Nothing connected to any of the four the Deployment Terminals.

Beeps enabled. One long beep about every 7 or 8 sec.

I can now load Flights from my Sim'd Flights.

Accel 16g is still offline ( Pink Background ).

Tried Accelerometer Calibration but it does not respond to Record Axis now.

Tried a Sim Flight but it continues to increment the Flight Time without any Axial Accel.

HTH

Thanks !

-- kjh
 
Last edited:
Edit: I reloaded the same firmware ( 7d4488f - 05/04/2023 09:50:51 ) and I've got a green Accel 16g again.

Will follow up.

Adrian --

I Calibrated the Accelerometer from the Phone App and it prompted me for the three-axis orientations ( new feature ).

I let it run until the Battery Level was 3.86 Volts and Shut Down the Blue Raven.

I charged the Battery ( 30-min for a Green Light )

Rebooted the Blue Raven and then connected via Bluetooth from my Android Phone.

Boot up beeps were normal ( long, short, 4-beeps )

Accel 16g is now offline ( Pink Background ).

Accel 400g and Gyro are Green

Tried to look at the Flights and all I saw was NaN Error after selecting a Simulated Flight.

...

Shutdown the Blue Raven and did a Force-Stop on the Android App.

Restarted the Blue Raven and the Android App.

Nothing connected to any of the four the Deployment Terminals.

Beeps enabled. One long beep about every 7 or 8 sec.

I can now load Flights from my Sim'd Flights.

Accel 16g is still offline ( Pink Background ).

Tried Accelerometer Calibration but it does not respond to Record Axis now.

Tried a Sim Flight but it continues to increment the Flight Time without any Axial Accel.

HTH

Thanks !

-- kjh
It sounds like there may have been a problem when you re-calibrated the accel. The calibration procedure is designed to reject invalid calibration orientations, and to not save until all 6 orientations have valid recorded values, but it sounds like something went wrong. I would try the cal again, and take a screenshot when all 6 orientations are recorded (each of the 6 diagrams has a value) before pressing the "Finished" button.
 
Last edited:
Adrian --

Charging the Blue Raven now.

Should I be trying to do Accelerometer Calibration in the Android App or should I use the Windows Software ?

The reason I ask is because in the Android App, the [Record Axis] button only stays active for about 1-sec and then goes grey and I can't figure out how to reactivate it after I miss my window to press the [Record Axis] Button.

Is there a sequence to follow to get it back ?

Thanks

-- kjh
 
Adrian --

Attached is a Screen Shot of the Accelerometer Calibration Screen from the Android App.

-- kjh

p.s. I figured out how to kill the16g Acceleromerer: Try running the Calibration App with the Battery Charger Plugged in.

I did and had to reinstall the firmware to restore the 16g Accelerometer Data.
 

Attachments

  • BLRV_0236-Cal.jpg
    BLRV_0236-Cal.jpg
    531.5 KB · Views: 0
Adrian --

Charging the Blue Raven now.

Should I be trying to do Accelerometer Calibration in the Android App or should I use the Windows Software ?

The reason I ask is because in the Android App, the [Record Axis] button only stays active for about 1-sec and then goes grey and I can't figure out how to reactivate it after I miss my window to press the [Record Axis] Button.

Is there a sequence to follow to get it back ?

Thanks

-- kjh
The record axis button is only enabled when one of the 6 orientations is aligned with gravity. The other cross-axis values need to be +/- 0.025 Gs. You'll need to tilt a little one way or the other to get the axis aligned more precisely with gravitiy.
 
The record axis button is only enabled when one of the 6 orientations is aligned with gravity. The other cross-axis values need to be +/- 0.025 Gs. You'll need to tilt a little one way or the other to get the axis aligned more precisely with gravitiy.
Thank you !

I'll play some more :)

-- kjh

EDIT: I got it now. I'll need to adjust the fit in the AV-Bay a tad to square up (x,y,z) with the AV-Bay ...
 
Last edited:
Adrian --

A little more info...

All it takes to Kill Accel 16g on my SN 0236 firmware 7d4488f is to power up with the Battery Charger plugged in.

Reinstalling the firmware restored the 16g Accelerometer.

-- kjh

p.s. I was able to power up the Blue Raven on the Charger yesterday on firmware e1ca8f8 withour losing the a6g Accelerometer
 
Back
Top