How to add an external capacitor to a Blue Jay

The Rocketry Forum

Help Support The Rocketry Forum:

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

FredT

Well-Known Member
TRF Supporter
Joined
Jan 22, 2009
Messages
358
Reaction score
55
My winter project this year is to modernize the electronics on some of my multi-stage rockets. I prefer to arm upper stage electronically remotely instead to climbing a latter. I have been using the combination of an EggFinder Wi-Fi Switch and a StratoLogger for backup deployment, with Blue Jays. The one concern I have with using Blue Jays for this their lack of a capacitor for momentary power dropouts. I had the same concern with the Wi-Fi Switch and just wired a capacitor across the battery on the other side of a switch. I always thought there should be a resistor and/or diode someplace in the circuit but didn't know how to do it and left it off. The circuit has proven to be reliable and decided to try it with the Blue Jay. Because this would free up AV bay space, I wanted to add a FeatherWeight Tracker to the mix. Anyways, the circuit I came up with is in the PDF. I haven't yet bypassed the Blue Jay's mag switch, but I plan to.

The good news is that it works. The bad news is my Blue Jay is now damaged... in a strange way. After waiting a few seconds for the cap to charge the tracker becomes active can connects to the app via Bluetooth, I active the Blue Jay with the mag switch. It flashed its LEDs and beeps out for about two seconds, then goes dark and silent and doesn't show any Bluetooth activity. But then in about 50 seconds it comes to life, with complete functionality, including firing charges. It exhibits this behavior when removed from the board and directly connected to the battery.

So, I'm happy, I guess? Just wondering why it's behaving that way. Also, any suggestions on adding a resistor and/or cap?

...Fred
 

Attachments

  • Circuit Diagram.pdf
    52.1 KB
I've not messed with my circuitry ( nor would I know how to do that ) ...

Does the Blue Jay download your two files after you run a sim or a ground test ?

-- kjh

EDIT: sorry ... I replied on my phone and reading my reply on my Laptop, it now seems terse :(
 
Last edited:
My winter project this year is to modernize the electronics on some of my multi-stage rockets. I prefer to arm upper stage electronically remotely instead to climbing a latter. I have been using the combination of an EggFinder Wi-Fi Switch and a StratoLogger for backup deployment, with Blue Jays. The one concern I have with using Blue Jays for this their lack of a capacitor for momentary power dropouts. I had the same concern with the Wi-Fi Switch and just wired a capacitor across the battery on the other side of a switch. I always thought there should be a resistor and/or diode someplace in the circuit but didn't know how to do it and left it off. The circuit has proven to be reliable and decided to try it with the Blue Jay. Because this would free up AV bay space, I wanted to add a FeatherWeight Tracker to the mix. Anyways, the circuit I came up with is in the PDF. I haven't yet bypassed the Blue Jay's mag switch, but I plan to.

The good news is that it works. The bad news is my Blue Jay is now damaged... in a strange way. After waiting a few seconds for the cap to charge the tracker becomes active can connects to the app via Bluetooth, I active the Blue Jay with the mag switch. It flashed its LEDs and beeps out for about two seconds, then goes dark and silent and doesn't show any Bluetooth activity. But then in about 50 seconds it comes to life, with complete functionality, including firing charges. It exhibits this behavior when removed from the board and directly connected to the battery.

So, I'm happy, I guess? Just wondering why it's behaving that way. Also, any suggestions on adding a resistor and/or cap?

...Fred
What is your main battery?
When the battery connects to the capacitor 0.1F you have a dead short for a fraction of a second. You should limit that current with a resistor. 4.7 Ohms will limit current in and out to about 2 Amps plus whatever the battery can supply at the same time. So if you were powered with a 9v battery that would be around 6 amps.
I'd guess one of the issues is that large load of the capacitor is causing the 9v battery voltage to sag sufficiently that your delay is it waiting for the chemical reaction internally to catch up.
Check the battery voltage and plot it every couple of seconds to get a better idea of what the voltage is dolng.
Also you could have damaged the wifi switch as the surge current will be outside its limits.
The other thing is that equipment does not like being powered up slowly. By pulling the voltage down and it then slowly recovering, your equipment is coming back up to operational voltages slowly. This is really bad!!!!! Some components could be in the off state while others are already in the on state. Effectively you're creating your own brownout.
https://en.wikipedia.org/wiki/Brownout_(electricity)
see digital systems.
 
Last edited:
Just one file (low rate)for each flight. The Blue Jay does not collect high data by design to lower its cost.
Sorry I wasn't clear.

I wrote my original reply on my phone and it seems terse now that I read it on my PeeCee :(

By two files I meant the Summary file and the Low_Rate file.

The reason I asked is because my Blue Jay behaves the same way during boot up.

When I turn on the Mag Switch, the boot up led and beep pattern seem about correct.

Then it 'goes dark' for about a minute until it finally connects with my Samsung Androud phone.

From that point on, the beeper and leds flash as expected.

But when I run a sim or a ground test, the bulbs lite up as expected but I get no on-screen summary of the data nor do the two files download.

When I force a download via the Icon on the Flights Screen, the files contain odd data.

-- kjh
 
I had never checked. But now I can report the same behavior as per the two files. Of course, data from an actual flight is what matters. I won't be flying it any time soon.

...Fred
 
My winter project this year is to modernize the electronics on some of my multi-stage rockets. I prefer to arm upper stage electronically remotely instead to climbing a latter. I have been using the combination of an EggFinder Wi-Fi Switch and a StratoLogger for backup deployment, with Blue Jays. The one concern I have with using Blue Jays for this their lack of a capacitor for momentary power dropouts. I had the same concern with the Wi-Fi Switch and just wired a capacitor across the battery on the other side of a switch. I always thought there should be a resistor and/or diode someplace in the circuit but didn't know how to do it and left it off. The circuit has proven to be reliable and decided to try it with the Blue Jay. Because this would free up AV bay space, I wanted to add a FeatherWeight Tracker to the mix. Anyways, the circuit I came up with is in the PDF. I haven't yet bypassed the Blue Jay's mag switch, but I plan to.

The good news is that it works. The bad news is my Blue Jay is now damaged... in a strange way. After waiting a few seconds for the cap to charge the tracker becomes active can connects to the app via Bluetooth, I active the Blue Jay with the mag switch. It flashed its LEDs and beeps out for about two seconds, then goes dark and silent and doesn't show any Bluetooth activity. But then in about 50 seconds it comes to life, with complete functionality, including firing charges. It exhibits this behavior when removed from the board and directly connected to the battery.

So, I'm happy, I guess? Just wondering why it's behaving that way. Also, any suggestions on adding a resistor and/or cap?

...Fred
What's the FWT in your diagram? When the Blue Jay powers on, it connects the + side of both charges to the + of the battery. When it fires a charge, it also connects the - side of the terminal to the - of the battery input. If the resistors shows in your diagram are charges and the rectangle with the terminals is the Blue Jay, then the charges would fire as soon as you power on.

The only time I've seen a Blue Jay go dark like you described is when the part of the firmware that does the over-the-air firmware update is running. On the devices page, what does it say for the app version and the firmware version?
 
Also, adding a capacitor is not necessary to prevent brownout. An ematch normally fires in less than 1 msec. But if the ematch causes a short circuit, the Blue Jay will stay running for about 15 msec without any power from the battery, which is plenty of time for it to recognize an imminent brownout and turn the output switch off. This way the Blue Jay will continue to operate the rest of the flight normally, firing any other ematches that come later in the flight. Adding a capacitor through any of the user-accessible terminals would basically just give you a slightly bigger battery and wouldn't have any impact on the Blue Jay's behavior in the event of an output short. If you soldered one into the internal 3V power on the board, the only effect it would have is to delay the time before the Blue Jay switches the output off in the event of an output short.
 
What is your main battery?
I've tried two batteries, both 1S Lipo one was 400mah with protective circuitry the 800mah without protection. Both showed identical behavior. Thanks for the tip, I have some 2 Ohm, 1-Watt resistors around. I put two in series. Didn't change behavior but seems like the right thing to do.

What's the FWT in your diagram? When the Blue Jay powers on, it connects the + side of both charges to the + of the battery. When it fires a charge, it also connects the - side of the terminal to the - of the battery input. If the resistors shows in your diagram are charges and the rectangle with the terminals is the Blue Jay, then the charges would fire as soon as you power on.
FWT is a Featherweight Tracker that uses the same battery and switch. The diagram was wrong. Correct diagram, now the 4 ohm resistor is included below.
The only time I've seen a Blue Jay go dark like you described is when the part of the firmware that does the over-the-air firmware update is running. On the devices page, what does it say for the app version and the firmware version?
I have two Blue Jays, #131 and #132. Both are: 83aba0b 11/11/2024 13:58:58, just different by 30 seconds.
Also, adding a capacitor is not necessary to prevent brownout. An ematch normally fires in less than 1 msec. But if the ematch causes a short circuit, the Blue Jay will stay running for about 15 msec without any power from the battery, which is plenty of time for it to recognize an imminent brownout and turn the output switch off.
The capacitor is to protect against the chatter in the external switch. I intend to bypass the device's mag switch eventually, just haven't yet. I know that there are different ways to accomplish my goal by using the mag switch and not adding the cap. This way in line with the flying procedures I have been using and refined over the years. It's not that I can't change, it's just easier not to.

I purchased the two BJ's in early November and quickly tested their functionality when I received them. The test was an ad hoc arrangement using the 400mah battery and Christmas tree lights. To the best of my recollection, I don't remember the 50 second darkness after turning on.

I just recently built the sled. Yesterday I tested the sled with BJ#131 that I noticed the 50-second darkness after the initial turn-on beeps and flashes. Now it always goes through that 50 second period of darkness when on the sled or isolated from it. Yesterday I powered on BJ#132 in an isolated environment, and it didn't go into darkness (#132 was never used on the sled). Today, after reading the TJ has seen the same 50-second darkness, I retested #132. And you know what, it too is now going through the 50-second darkness. I'm beginning to question my own sanity:).

I am not bothered by the 50 seconds of darkness. I know it's there and I know it will pass I can deal with it. But it is baffling.

...Fred


Circuit Diagram.jpg
 
I've tried two batteries, both 1S Lipo one was 400mah with protective circuitry the 800mah without protection. Both showed identical behavior. Thanks for the tip, I have some 2 Ohm, 1-Watt resistors around. I put two in series. Didn't change behavior but seems like the right thing to do.


FWT is a Featherweight Tracker that uses the same battery and switch. The diagram was wrong. Correct diagram, now the 4 ohm resistor is included below.

I have two Blue Jays, #131 and #132. Both are: 83aba0b 11/11/2024 13:58:58, just different by 30 seconds.

The capacitor is to protect against the chatter in the external switch. I intend to bypass the device's mag switch eventually, just haven't yet. I know that there are different ways to accomplish my goal by using the mag switch and not adding the cap. This way in line with the flying procedures I have been using and refined over the years. It's not that I can't change, it's just easier not to.

I purchased the two BJ's in early November and quickly tested their functionality when I received them. The test was an ad hoc arrangement using the 400mah battery and Christmas tree lights. To the best of my recollection, I don't remember the 50 second darkness after turning on.

I just recently built the sled. Yesterday I tested the sled with BJ#131 that I noticed the 50-second darkness after the initial turn-on beeps and flashes. Now it always goes through that 50 second period of darkness when on the sled or isolated from it. Yesterday I powered on BJ#132 in an isolated environment, and it didn't go into darkness (#132 was never used on the sled). Today, after reading the TJ has seen the same 50-second darkness, I retested #132. And you know what, it too is now going through the 50-second darkness. I'm beginning to question my own sanity:).

I am not bothered by the 50 seconds of darkness. I know it's there and I know it will pass I can deal with it. But it is baffling.

...Fred


View attachment 684032
You should use the + terminals on the Blue Jay for your ematches rather than connecting the high side straight to the battery. The + terminals turn on with a delay to ensure that the microcontroller is up and running before power goes to the high side of the ematches. The microcontroller datasheet says that its outputs don’t glitch during startup, but better to be safe than sorry.

Tomorrow I’ll see if I can reproduce the 50 second blackout issue with my Android phone.
 
Last edited:
Thanks to @kjhambrick's Blue Jay, I found the firmware bug that was causing the 50 second startup issue, and issues with the flash recording that pop up if you have had a very long (real or simulated) flight that fills up the low rate data allocation. I have re-tested a corrected version with a 40 minute long flight, and the firmware is behaving correctly now. I think the app still has a separate problem with the downloading but hopefully it won't take too long to release a new phone app build with the new firmware that clears up the Blue Jay downloading issues.
 
Interesting !

Looking back at my notes, I may have broken my Blue Jay when I messed with the Sim Parameters so I could try to send it into space.

I did the sim because I wanted to see what happened with pressure -to- altitude conversions with the new barometer if ever it went 'way up there'.

The Blue Raven displays 'Infinity' when the baro altitude exceeds 250,583.1 ft MSL ( the pressure is stored in the low_rate file as 0.0000 atm ).

I think I set up the Blue Jay sim for 80 G for 5 sec ( ? about a 10-min flight ? ) but the sim "lost it's mind" well before apogee ( for example, it was still ascending but it was displaying negative velocity which made me wonder about an overflow on the velocity integration ).

Sorry, but I never associated that crazy sim with the boot problem I was having ... I was wondering if I might have shorted out the nekkid PC board somehow.

Q1A: What is the longest possible recorded Flight Time in the Blue Jay's on-board, low rate memory buffer at 50Hz ?

Q1B: Put another way ... how many seconds of 50 Hz data can I record before EoF ?

And ...

Q2: Might the same issue occur with the Blue Raven ?

I've run several crazy sims on different Blue Ravens and while it loses it's mind on the way up, it does not seem to affect the operation.

For the Blue Raven, Flight_Time_(s) = 573.46 sec in the low_rate file and Flight_Time_(s) = 381.974 sec in the high_rate file.

Thanks for the feedback Adrian !

-- kjh
 
Last edited:
Interesting !

Looking back at my notes, I may have broken my Blue Jay when I messed with the Sim Parameters so I could try to send it into space.

I did the sim because I wanted to see what happened with pressure -to- altitude conversions with the new barometer if ever it went 'way up there'.

The Blue Raven displays 'Infinity' when the baro altitude exceeds 250,583.1 ft MSL ( the pressure is stored in the low_rate file as 0.0000 atm ).

I think I set up the Blue Jay sim for 80 G for 5 sec ( ? about a 10-min flight ? ) but the sim "lost it's mind" well before apogee ( for example, it was still ascending but it was displaying negative velocity which made me wonder about an overflow on the velocity integration ).
In my long flight test (I think it was 10 Gs for 30 seconds IIRC) the real-time sim displayed values were goofy but the underlying model was still working, and I think the Blue Jay fired both of its charges at appropriate times.
Sorry, but I never associated that crazy sim with the boot problem I was having ... I was wondering if I might have shorted out the nekkid PC board somehow.
Your Blue Jay is working fine now with the new firmware.
Q1A: What is the longest possible recorded Flight Time in the Blue Jay's on-board, low rate memory buffer at 50Hz ?
6.7 minutes

Q2: Might the same issue occur with the Blue Raven ?
No, this issue was just that I had a typo in my code when I put in the Blue Jay's (smaller) maximum flash size, that only made itself apparent with flight that filled up the flash memory.
I've run several crazy sims on different Blue Ravens and while it loses it's mind on the way up, it does not seem to affect the operation.

For the Blue Raven, Flight_Time_(s) = 573.46 sec in the low_rate file and Flight_Time_(s) = 381.974 sec in the high_rate file.

Thanks for the feedback Adrian !

-- kjh
 
Back
Top