Featherweight Blue Raven Development Thread: Recorded time-series data

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,170
Reaction score
2,842
Location
Lakewood, CO
I meant to post about the recorded data as its own development thread earlier, but I've been busy...

Yesterday I tweaked the flash memory allocations for the firmware that is going into the pre-order Blue Ravens I'm prepping now.

The Blue Raven collects and records data at two different rates: 50 samples per second for most measurements, and 500 samples per second for measurements that can change that quickly. Both sets of data record a sync code at 1 msec resolution that ensures the data can be aligned properly when graphing together Here is the 500 sample/second list:

  • Gyroscope X, Y, and Z rates
  • X, Y, and Z accelerations, which uses the +/- 32G range acclerometer for any readings under 32 Gs, and the +/- 400G accelerometer for any other readings.
  • Attitude quaternion (X, Y, Z axis terms and theta magnitude term). The attitude quaternion provides the full orientation of the altimeter relative to what it was at the pad
  • Deployment output current. This is the combined current from all 4 outputs
  • Aux analog voltage. There is an auxilliary analog input with its own plated through hole on the board for external sensors for chamber pressure, etc. The range is 0-2V full scale
  • sync code
I wasn't originally planning to but both of those analog measurements into the 500 Hz data, but it turned out I could pack the recorded data onto the flash chip more efficiently that way. Here is the list of data recorded 50 times per second:

  • Local time synchronized with your phone's time. Hours, minutes, seconds, and milliseconds.
  • 3D inertial navigation upward velocity, computed from integrating data over time from the the gyroscope and accelerometer
  • 3D inertial navigation down-range (DR) velocity, in the direction of the initial rocket tilt at the pad
  • 3D inertial navigation cross-range (CR) velocity, in the direction perpendicular to the first 2 directions. The DR and CR velocities are combined to compute the horizontal velocity
  • 3D inertial navigation altitude, in feet
  • 3D inertial navigation down-range distance, in feet
  • 3D inertial navigation cross-range distance, in feet
  • Tilt angle. The angle between the upward direction and the rocket axis. This is calculated from the attitude quaternion and the measured direction of the first motion along the rail. This is directly useful for ensuring safety during airstarts.
  • Future tilt angle. Uses the 3D inertial navigation horizontal and vertical velocity to predict what the tilt angle will be looking 3 seconds ahead, which can be useful for estimating tilt after a relatively long airstart ignition delay.
  • Roll angle. A simple integration of the roll rates around the rocket axis (not derived from the quaternion attitude, so this value will keep going up as your rocket spins multiple revolutions). This will tell you how many times the rocket spun. Could be used in a who-had-straighter-fins competition
  • Battery voltage, in mV
  • Apo channel continuity voltage, in mV
  • Main channel continuity voltage, in mV
  • 3rd channel continuity voltage, in mV
  • 4th channel continuity voltage, in mV
  • Barometric pressure, in atm, with 1/50,000 atm resolution
  • Temperature measured by the barometric pressure sensor, in degrees F with 2 decimal places
  • Commands for 3 servo outputs (potential future capability)
Flight events compressed into something I call Flight Event Registers (FER). The flight event registers tell you not only exactly why your charges fired when they did, but they also let you figure out when they would have fired during your flight if you had picked different deployment settings. There are four sets of channel-specific flight event register and one rocket-level FER.
  • Flight event register for each deployment channel. Each channel has a list of conditions that checks during the flight, such as altitude above the pad is above a user threshold, or altitude above the pad is below a different user threshold, etc. There are 12 conditions that can change during the flight, and they are each recorded in the FER whether or not they are selected to be used to decide whether to fire the channel. Each of the 4 channels has its own set of user-defined thresholds, so each gets its own channel FER.
    • AGL (baro-based) altitude less than user threshold AGL1 (used for main deployment)
    • AGL (baro-based) altitude greater than user threshold AGL2 (used for airstarts)
    • Tilt angle less than user threshold FANG1 (used for airstarts)
    • Tilt angle greater than user threshold FANG2 (used for airstarts or secondary apogee charge logic)
    • Future angle greater than user threshold FUTANG (can be used for airstarts)
    • Time from liftoff detection less than user threshold TVAL1 (could be used for airstarts)
    • Time from liftoff detection greater than user threshold TVAL2 (basic timer, deprecated for airstarts)
    • Barometric velocity less than user threshold BVEL (used to detect apogee charge failure)
    • Axial velocity less than user threshold VEL1 (airstarts or separation events or Mach lockout for baro-based deployments)
    • Axial velocity greater than user threshold VEL2 (airstarts)
    • Burnout counter greater than user threshold: (prevent deployments during motor burn, or multi-stage logic)
    • Channel is armed. Default settings arm the drogue and main deployments at power up but airstarts and stage separations are armed remotely at the pad
  • Flight event register for the rocket as a whole. These are additional conditions that are recorded and checked that don't depend on the individual thresholds selected for each channel.
    • Liftoff detected
    • Apogee detected (fault tolerant to sensor failure by voting baro sensor, gyros, and accels)
    • Barometric pressure increasing
    • Motor coast detected in burnout counter logic
    • Apogee charge fired 1 second ago
    • Main charge fired 1 second ago
    • 3rd channel fired 1 second ago
    • 4th channel fired 1 second ago
    • Rocket is in a nominal ascent (a user-settable maximum tilt angle has not yet been exceeded since launch)
    • Accel-only velocity check is less than zero (integrates only axial acceleration and assumes vertical flight)
    • Inertial navigation vertical velocity less than zero (useful for exo-atmospheric flights where the gyro tilt angle may exceed 90 degrees before apogee)

The high-rate data is recorded for up to 6.4 minutes, and the low-rate data is recorded for up to 22.4 minutes. The flash memory is split into 2 flights so that the altimeter can erase one bank to get ready for launch while keeping the most recent flight available for re-downloading.
 
Hi Adrian,
I'm very interested in the Aux Analog Voltage input or inputs. We mount thermistors on the outside of our rockets to monitor the external temperature, so recording the voltages on the Blue Raven would be really handy. Do you have more details? I've looked closely at the front and back board views and I can't find the plated holes for the Aux inputs. None of the documentation mentions where to get the data during download. Any info you could provide would be greatly appreciated. I place my order yesterday to get one to test.
 
Hi Adrian,
I'm very interested in the Aux Analog Voltage input or inputs. We mount thermistors on the outside of our rockets to monitor the external temperature, so recording the voltages on the Blue Raven would be really handy. Do you have more details? I've looked closely at the front and back board views and I can't find the plated holes for the Aux inputs. None of the documentation mentions where to get the data during download. Any info you could provide would be greatly appreciated. I place my order yesterday to get one to test.

1681512256195.png

This is the plated through-hole on the board that measures aux voltage input. If your source is higher than 2V, you will need to scale it down with a resistor divider. The voltage at output terminal is also recorded, though at 50 Hz rather than 500 Hz, and the max voltage for those is around 20V. Both types are 12-bit measurements.
 
View attachment 574924

This is the plated through-hole on the board that measures aux voltage input. If your source is higher than 2V, you will need to scale it down with a resistor divider. The voltage at output terminal is also recorded, though at 50 Hz rather than 500 Hz, and the max voltage for those is around 20V. Both types are 12-bit measurements.
Thank you. I’ll give it a try once mine comes in.
 
The latest Blue Raven phone app build (178) for iOS and Android now supports over-the-air download of the high-rate and low-rate data! Once the data is on your phone, you can share the data as an Excel file in any of the ways that your phone is connected, including email, OneDrive, Google Drive, etc.

The downloading starts automatically when you walk up to your rocket after the flight and continues while you bring it back to camp. In the meantime while it's downloading (it takes a while) you can review all the flight summary data.

20230518_211154862_iOS.png
 
Hi, Adrian

That's great! I recently purchased a Blue Raven. My Tsinghua University EE wife and I are rigging it up to run from a a piece of cutting board plastic, instead of from a Perch. Hoping to launch it on a Green Egg platform come Saturday.

Naturally I'm concerned that we'll lose it, that the jury-rig won't work out in time, or that the weather will not cooperate and push the launch another month.

Any chance you could post a .csv file from a flight or two? ...Just for sample data to fool around with? (Of course, "No" is a perfectly good answer.)

Thanks either way, and best regards,

-Larry Curcio
 
Hi, Adrian

That's great! I recently purchased a Blue Raven. My Tsinghua University EE wife and I are rigging it up to run from a a piece of cutting board plastic, instead of from a Perch. Hoping to launch it on a Green Egg platform come Saturday.

Naturally I'm concerned that we'll lose it, that the jury-rig won't work out in time, or that the weather will not cooperate and push the launch another month.

Any chance you could post a .csv file from a flight or two? ...Just for sample data to fool around with? (Of course, "No" is a perfectly good answer.)

Thanks either way, and best regards,

-Larry Curcio
Larry !

Long time no 'see' !

I was [email protected] from the old rec.models.rockets days :)

Nice to see another familiar Data Geek on TRF !!

-- kjh
 
Last edited:
Hi, Adrian

That's great! I recently purchased a Blue Raven. My Tsinghua University EE wife and I are rigging it up to run from a a piece of cutting board plastic, instead of from a Perch. Hoping to launch it on a Green Egg platform come Saturday.

Naturally I'm concerned that we'll lose it, that the jury-rig won't work out in time, or that the weather will not cooperate and push the launch another month.

Any chance you could post a .csv file from a flight or two? ...Just for sample data to fool around with? (Of course, "No" is a perfectly good answer.)

Thanks either way, and best regards,

-Larry Curcio
Larry,

All my real flight data is from when the only way to download was over USB serial, and the format is a little different. I can post that if you want. But you can also play with realistic-looking flight data from the Blue Raven’s flight simulation if you haven’t already. It adds accel and even gyro flight dynamics on top of the sensor measurements when sitting in the desk. Just be sure not to have anything connected to the outputs that you don’t want fired (I need to add a warning message about that)
 
Larry,

All my real flight data is from when the only way to download was over USB serial, and the format is a little different. I can post that if you want. But you can also play with realistic-looking flight data from the Blue Raven’s flight simulation if you haven’t already. It adds accel and even gyro flight dynamics on top of the sensor measurements when sitting in the desk. Just be sure not to have anything connected to the outputs that you don’t want fired (I need to add a warning message about that)
Thanks, Adrian. Will check the simulated stuff. The format isn't that important, tho. I'm mostly looking for real tilt angles, wherewith to compare angles from barometric/accelerometer combination data. (Trying to get more out of less elaborate flight computers.)
 
Been away a while. Good to find you here.
Yes, I've been away something like 23 years :)

I am a BABAR thanks to my two Granddaughters :) :)

I'm sure we'll be corresponding ... I am also the owner of a new Blue Raven and I am itching to send it up :) :) :)

Your Plastic Cutting Board Sled sounds interesting ... how thick is the material ?

-- kjh

p.s. As Adrian said, the BlueTooth Data Format is very different from the older USB Files.

If you're still a UNIX guy, I've written a q&d bash + gawk script to merge-sort the Low-Rate and High-Rate BlueTooth Files by SyncCode.

These run fine on my Linux Box and I'll even throw in a handy Perl Script to convert .xlsx to Delimited Text if you're interested.
 
Last edited:
Yes, I've been away something like 23 years :)

I am a BABAR thanks to my two Granddaughters :) :)

I'm sure we'll be corresponding ... I am also the owner of a new Blue Raven and I am itching to send it up :) :) :)

Your Plastic Cutting Board Sled sounds interesting ... how thick is the material ?

-- kjh

p.s. As Adrian said, the BlueTooth Data Format is very different from the older USB Files.

If you're still a UNIX guy, I've written a q&d bash + gawk script to merge-sort the Low-Rate and High-Rate BlueTooth Files by SyncCode.

These run fine on my Linux Box and I'll even throw in a handy Perl Script to convert .xlsx to Delimited Text if you're interested.
The cutting board plastic ia about 1.25 mm thick. It remains rigid, because we bend it around the internal circumference of the body tube, and wedge it between the nose cone and the lower bulkhead. The instrument is bolted to the plastic. We had to buy a cable to connect the battery - no biggie.

Actually, since retirement, I haven't had a UNIX of Linux system to play with. Should really install one. Your software is the incentive I'll need.

Am just about to do the simulation thing.

Also hoping for nice, linear response from the accelerometers. (Fingers crossed...)
 
The cutting board plastic ia about 1.25 mm thick. It remains rigid, because we bend it around the internal circumference of the body tube, and wedge it between the nose cone and the lower bulkhead. The instrument is bolted to the plastic. We had to buy a cable to connect the battery - no biggie.

interesting idea !

Do you use the Blue Raven for Ejection ( don't see why you couldn't with that setup ) ?

* * *

I do look forward to flying the Blue Raven in new 24, 29 and 38 mm Rockets where I can fly more and hike less ( or not :) )

All I needed to install the AltAcc was a pair of screwdrivers -- a small one to connect the squibs and another one to attach it to the inside wall of a Coupler and then to arm it.

I am still looking for a similar quick switch solution for the Blue Raven where I can do back-to-back ( ... to-back ... ) flights without a lot of AV-Bay setup.

So far I've not come up with anything better than Adrian's AV-Bay ( I've got both the 38 and 29 mm versions ).

But the Featherweight AV-Bay does not fit in the old rockets that I built around the AltAcc ( 48, 54, 75 and 98 mm ) so I am still thinking about it.

I received a Power Perch and a Mag Switch from Featherweight yesterday.

I love the Mag Switch and I can install the Power Perch on a plywood plank, AltAcc-Style with stand-offs so I can fly the Blue Raven in what I already have.

I am now pondering a 3-D Power Perch where the Mag Switch and the Battery are rotated behind ( ? underneath ? ) the Blue Raven and the 8-wire screw terminal is split into two, 4-wire screw terminals, one forward and one aft of the Blue Raven to reduce the width from ~39 mm down to ~24 mm ( or so ).

Anyhow, I've got a lot more options today than I did on Wednesday :)


Actually, since retirement, I haven't had a UNIX of Linux system to play with. Should really install one. Your software is the incentive I'll need.

I have not done much of anything yet.

So far, all I have done is figure out the Blue Raven Sync Codes so I can merge-sort Hi-Rate and Lo-Rate Data from the BlueTooth Output Files.

The Blue Raven simulated data looks great !

I need to fly the Blue Raven so I can start working with the real thing :)

I'll know a lot more after June 3 when I should be ready to fly at the AARG Launch.

I should have some actual flight data to mess with by then ...

My first project after that will probably be to get BlueTooth Comms working on Linux so I can capture raw Data in Real Time ( like FIP does with the older Raven Versions ).

I am also looking forward to Adrian's upcoming posts after he has flown his new Ejectable AV-Bay and gathered his data via the new Blue Tooth Inteface Programs.


Am just about to do the simulation thing.

Also hoping for nice, linear response from the accelerometers. (Fingers crossed...)

Did you want to test the electronic offset, gain and any n-th order effects of the onboard sensor chips ?

Or are you talking about reconciling Barometric and Inertial Data ( and maybe GPS position Info ) ?

-- kjh

p.s. I've not tested 'Windows Subsystem for Linux' because I run Linux so I don't need it :)

But from what I've read, Windows Version 10 or above will run Linux as a subsystem so maybe you don't need a Linux Box if WSL will run native Linux Binaries ...
 
Hi, Konrad
You'd be amazed at how primitive my flying has become. Florida, where I now reside, is the air traffic capital of the U.S.. Our club's ceiling is, therefore, 1200 feet. Deployment, you ask? This is strictly LP, which is fine. Having been a chem major, I'm not enthusiastic about storing loose BP. (OTOH, I'm not enthusiastic about seeing the instrument drift over the horizon either.) The Power Perch doesn't fit into this context, though my wife (the EE) likes the mag switch idea.

Did the simulation. It would be nice if it gave pressure altitude, but OTOH, it's nice to be fooling with something under development. I hate it when something is wrapped too tightly. The barnstorming element is everything, right?

Did the accelerometer calibration. It was... painful, but it will be better next time.

Am going to do a 2-dimensional (Hamiltonian) analysis of the data, using only the accelerometer and altimeter, thereby deriving things like tilt angle and horizontal speed/distance. The idea is to have 6 DOF data to compare the results with. This will require data interpolation or decimation, along with constant prayer, and fasting. (Have already burned the entrails of a goat...) So, anyway, inertial data does have to agree in some way with barometric data.

I remember the AltAcc fondly. A bit stairsteppy, but it did its job - as you did yours.

Best Regards
 
Larry --

Yes, calibration was a little touchy with the high-rez accelerometer compared to the old 8-bit single-axis AltAcc.

Scott made a few 'Black Sky AltAcc Cal Blocks' with a built in bubble-level... He kept S/N 001 and he gave me S/N 002 when I was developing the Firmware :)

Worked fine with the single-axis ADXL50 but now the bubble level is in my way for the 'face down' cal reading ...

Anyhow ...

I've been looking at the Sim'd LO-Rate and HI-Rate Data Sets and I like what I see.

These are the Pressure Events from a recent LO-Rate File .xlsx file:

Code:
#  SyncSec | Sync | Baro_Press_(atm) | Liftoff | Normal_Ascent | Burnout_Coast | Apogee | Apo_fired | Press_Increasing | Main_fired
     1.897 | 147  | 0.97608          | 0       | 0             | 0             | 0      | 0         | 0                | 0
     2.117 | 117  | 0.9761           | 1       | 1             | 0             | 0      | 0         | 0                | 0
     3.297 | 47   | 0.97036          | 1       | 1             | 1             | 0      | 0         | 0                | 0
     9.937 | 187  | 0.94546          | 1       | 0             | 1             | 1      | 0         | 0                | 0
    11.477 | 227  | 0.94678          | 1       | 0             | 1             | 1      | 1         | 0                | 0
    12.457 | 207  | 0.94884          | 1       | 0             | 1             | 1      | 1         | 1                | 0
    14.937 | 187  | 0.95324          | 1       | 0             | 1             | 1      | 1         | 1                | 1

These are the Pressure Altitudes using NOAA's Equation ( https://www.weather.gov/epz/wxcalc_pressurealtitude )

Code:
./p2a -z 0.97608 0.9761 0.97036 0.94546 0.94678 0.94884 0.95324

0.97608 raw -> 0.97608 atm -> 29.205 inHg ->  989.01 mb ->     668 ft
0.9761  raw -> 0.97610 atm -> 29.206 inHg ->  989.03 mb ->     668 ft ( dz = -1 ft )
0.97036 raw -> 0.97036 atm -> 29.034 inHg ->  983.21 mb ->     830 ft ( dz = 162 ft )
0.94546 raw -> 0.94546 atm -> 28.289 inHg ->  957.98 mb ->    1543 ft ( dz = 875 ft )
0.94678 raw -> 0.94678 atm -> 28.329 inHg ->  959.32 mb ->    1505 ft ( dz = 837 ft )
0.94884 raw -> 0.94884 atm -> 28.390 inHg ->  961.40 mb ->    1446 ft ( dz = 777 ft )
0.95324 raw -> 0.95324 atm -> 28.522 inHg ->  965.86 mb ->    1319 ft ( dz = 650 ft )

I like it :)

Looking forward to our upcoming discussions :)

Maybe we should open a new thread so we don't pollute Adrian's 'Featherweight Blue Raven Development Thread: Recorded time-series data' ?

-- kjh

p.s. Yes, I used to call the AltAcc Raw Pressure Graph 'The Stairway to (the) Heaven(s)' ( but given an 8-bit A2D and 1024 bytes of program memory, whatcha gonna do ? :) )

Here is one from a 1996 F12 Flight in an Aerotech Tomahawk at a Park near Round Rock, TX that has since become Dell Diamond ( Old Settlers Park ) ...
 

Attachments

  • f12-p.png
    f12-p.png
    12.8 KB · Views: 0
@Adrian A do you have a plan to support the blue raven with FIP? Flew a two stage and wanted to get the graphs but couldn't connect to FIP. Will the app show graphs like FIP dis for older ravens? Thanks
 
@Adrian A do you have a plan to support the blue raven with FIP? Flew a two stage and wanted to get the graphs but couldn't connect to FIP. Will the app show graphs like FIP dis for older ravens? Thanks
There’s no current plan, but if Kevin wants to adapt the FIP to accept the Blue Raven data, that would be great. I’ve been doing all my plotting in Matlab and Excel. The phone app will show graphs in an upcoming release, but it’s not the biggest screen for that.
 
@Adrian A

I will be flying my Blue Raven this weekend in a two-stage. I was wondering why the gyros show up red in the live data screen and why the 400g accel switches between red and green. I have the board in a near vertical position on my desk when the screen capture was taken. Does this indicate some sort of problem with these sensors?

...Fred
 

Attachments

  • Screenshot_20230531-150948.png
    Screenshot_20230531-150948.png
    180.4 KB · Views: 0
@Adrian A

I will be flying my Blue Raven this weekend in a two-stage. I was wondering why the gyros show up red in the live data screen and why the 400g accel switches between red and green. I have the board in a near vertical position on my desk when the screen capture was taken. Does this indicate some sort of problem with these sensors?

...Fred
The 400G accel threshold is a little too tight, so normal noise can cause it to go red. If the Blue Raven is sitting completely still, you should see the gyros go green. If it has just run a simulation and hasn't been reset back to prelaunch mode yet, then the gyro offsets won't get updated, which can cause them to read out of bounds.
 
The 400G accel threshold is a little too tight, so normal noise can cause it to go red. If the Blue Raven is sitting completely still, you should see the gyros go green. If it has just run a simulation and hasn't been reset back to prelaunch mode yet, then the gyro offsets won't get updated, which can cause them to read out of bounds.
Thanks, it's reading correctly now. I think it might have been some ground testing I've done with Xmas lights.
 
Yesterday I received an Email announcing availability of Build 190 (Android). I installed the new version last night. But when I launched app all I saw was a blank screen. I ended up removing the app and installing a previous version, which seem to work as before, but I have yet to exhaustively test it. Has anyone got build 190 to work? Is it worth the upgrade.

Thanks.

...Fred
 
Fred --

I saw the notification this morning but I am out of town at a conference for work and I didn't bring my Blue Raven with me so no, I've not tried updating my Firmware nor the Android App yet ( it's killin' me :) )

Sorry ...

-- kjh
 
Apparently de-installing your previous version (and deleting the previously stored data) is necessary. Let me know if that doesn’t work for installing build 190.

This app build does not update the firmware.
 
what is the max recommended capacity lipo for the blue raven? Is it still the same as the Raven4? I would like to share the battery with the altimeter and featherweight gps but want as much capacity as possible.
 
what is the max recommended capacity lipo for the blue raven? Is it still the same as the Raven4? I would like to share the battery with the altimeter and featherweight gps but want as much capacity as possible.

For now, it's the same as the Raven. The FETs are rated for 20 Amps for 1 second. For a 4V cell, you need at least 200 mOhms of internal resistance to limit a short circuit to 20 Amps. When I was igniting an upper stage a couple of weeks ago, the 160 mAhr battery delivered about 5 Amps when it was firing into a an ignited motor (a pretty hard short), so the user's manual requirement of 180 mAhrs or less for a 1S battery is probably conservative.

Larger 1s batteries like you would use for a tracker usually have built in cell protection circuitry. If you use one of these, you could go up much higher in capacity but you would run the risk of the battery turning itself off and not turning back on again. I just tried this by doing a ground test through the app with the 2000 mAhr battery used in the ground stations. When the output load was 3.3 Ohms, I got the expected current of about 1 Amp and everything worked fine. But when I re-tried the experiment with a short, the battery turned itself off and never turned back on again.
 
For now, it's the same as the Raven. The FETs are rated for 20 Amps for 1 second. For a 4V cell, you need at least 200 mOhms of internal resistance to limit a short circuit to 20 Amps. When I was igniting an upper stage a couple of weeks ago, the 160 mAhr battery delivered about 5 Amps when it was firing into a an ignited motor (a pretty hard short), so the user's manual requirement of 180 mAhrs or less for a 1S battery is probably conservative.

Larger 1s batteries like you would use for a tracker usually have built in cell protection circuitry. If you use one of these, you could go up much higher in capacity but you would run the risk of the battery turning itself off and not turning back on again. I just tried this by doing a ground test through the app with the 2000 mAhr battery used in the ground stations. When the output load was 3.3 Ohms, I got the expected current of about 1 Amp and everything worked fine. But when I re-tried the experiment with a short, the battery turned itself off and never turned back on again.
Also, on my firmware to-do list is to respond to an output over-current event by reducing the duty cycle of the output switches. Currently they are on 99% of the time, with a hardware-controlled square wave that's too fast to notice except for what looks like noise that shows up in the recorded voltage and current data. I haven't settled on the over-current threshold, but it will probably be between 4 and 10 Amps.
 
For now, it's the same as the Raven. The FETs are rated for 20 Amps for 1 second. For a 4V cell, you need at least 200 mOhms of internal resistance to limit a short circuit to 20 Amps. When I was igniting an upper stage a couple of weeks ago, the 160 mAhr battery delivered about 5 Amps when it was firing into a an ignited motor (a pretty hard short), so the user's manual requirement of 180 mAhrs or less for a 1S battery is probably conservative.

Larger 1s batteries like you would use for a tracker usually have built in cell protection circuitry. If you use one of these, you could go up much higher in capacity but you would run the risk of the battery turning itself off and not turning back on again. I just tried this by doing a ground test through the app with the 2000 mAhr battery used in the ground stations. When the output load was 3.3 Ohms, I got the expected current of about 1 Amp and everything worked fine. But when I re-tried the experiment with a short, the battery turned itself off and never turned back on again.
I have some 300mAhrs 1s batteries with 75C printed on the label which I think is really stretching it. 75C is good marketing but i'm not sure the batteries i have can actually deliver that discharge rate. If I did the math right that comes to about 22.5Amps max discharge current, how does the published discharge rate of a lipo compare with your internal resistance metric?
 
Back
Top