(cross-posted from rocketry planet)
I've been putting off ordering another batch of Parrot parts, Parrot batteries, Parrot circuit boards, etc. etc, but the time has come. I'm out of Parrots that have been calibrated for the standard baro range (0-30kft), and I'm down to my last 3 with the extended baro range (0-100+ kft). There are a couple of changes that I needed to make to the back side of the board for easier manufacturing, so I'm going to make brand-new boards. I was already planning to do 15 out of the next 40 with 250G accels, but now that the hood's up, I can't resist the urge to make some additional improvements. Here's what I have incorporated into the layout so far:
- 3 independent outputs: Burnout, Apogee, and ~800 ft altitude. Each capable of over 4 Amps for 1 second.
- Built-in screw switch for arming
- A 6-position, .1" pitch screw terminal block across the top for the outputs and the pyro battery.
- A new smaller beeper on the back
- Better mounting hole layout (2 holes) with enough room to accomodate 4/40 screws and standoffs
The altimeter is still just as narrow (0.63") as before, but now the circuit board is a bit longer where the beeper used to hang off the top, so the assembled length is 2.20", rather than 2.15" long. In order to stuff it into an Estes 18mm nosecone like the original Parrot, the screw terminals would have to be removed so that the front end could be sufficiently tapered.
Code space limitations have been keeping me from doing a purpose-built multi-deployment altimeter, because I wouldn't have room to put in a lot of deployment-related software features that I might want, including adjustable deployment altitude, adjustable delay time, in-flight current measurement, etc. Since then, though, I have come to the opinion that it would still add a lot of value to add a non-adjustable deployment low-altitude deployment, and a third output while I'm at it. The Parrot would still have an accel-based automatic Mach inhibit.
Given the interest in the top speed contest at this year's LDRS, I'm thinking that a staging output based on burnout (< 1G? <0G's?) would be the best use of the 3rd output.
Other options that have been suggested include:
- Using the 3rd output as a 2nd stage enable switch, which could be combined with an external timer so that when the timer goes off, the 2nd stage would only ignite if the rocket were going within 45 degrees or so of vertical
- Making the 3rd output an apogee deployment, but based solely on the accel, so it could be used in a sealed av bay
- Some sort of backup deployment based on descent rate
What do you guys think? Considering the Parrot's severe self-imposed size constraint, and the code space constraint, I don't know how much more I can fit in, but I'd love to hear any suggestions.
My only suggestion would be to change the data output frequency on the USB port from 1Hz to 10Hz or ideally 100Hz... or better yet, make it polled.
Warren
Warren,
I'll see what I can do, while still keeping it general-purpose. 10 Hz may be do-able. The real-time data is 8 columns of ASCII, coming out at 115kbps, so faster than that would probably be too fast. Maybe even 10 Hz, but I'll see. A polled interface would require a special set of code for your application.
My preference (and likely that of the bulk of your buyers) is to have apogee dual deployment. Especially with altitude birds, motor delays just aren't long enough and you want it to "pop at the top" (or past) to get max altitude.
I don't mind adding another battery to handle the deploy duties, but if I'm prepping one charge, I might as well be doing two.
Also, does my Parrot have the latest code (and chamber calibrations)? How do I check?
If I get the time, I may try making up a GUI for it in Labview.
Thanks,
Ken
Ken,
One of the three outputs will be a baro-based at apogee. Did you mean that you wanted two of the 3 charges to do that? If an ematch or pyro prep failure is a concern, two charges could be run off of the same output, if the battery can handle it and the total current is 5-6 Amps or less (the FET is rated for 4.1 A for less than 5 seconds, or 12 A for .1 msec).
Your Parrot does have the latest calibrations and latest apogee code. A Labview GUI would be cool. Could non-Labview users use the results?
I'm still not quite clear on it, I guess. I thought the existing code would do a fixed "low altitude main" deployment, and apogee was up to the user to figure out. I would like a single charge at apo, and a single at a fixed (or setable) low altitude.
We have one machine at work that has the compiler licence. Once I get something working acceptably, we should be able to make a .exe. We've been having issues generating an install kit so far, but we're still coming up on that part of Labview. Weird language. You could do an inverse hyperbolic cotangent of a 5 dimensional array in a single command, but there isn't a command to clear an array. 🙄
Ken
Ken,
I have programmed a few existing Parrots to do a low-altitude main deployment (like the one I used for my cert flights), but most have been programmed with a default baro-based, mach-inhibited apogee deployment. The new version would have both, on separate outputs, plus a third based on TBD, but probably burnout.
Wow, if you could help make a stand-alone a front end, I would be eternally grateful.
Darn, I was looking for a tool to do an inverse hyperbolic cotangent of a 5 dimensional array just the other day. 😉
Later I'll post more on some cool new features I have incorporated into the firmware while waiting for the board assembly to get done, but first a status update:
The board assembly turned out to be a nightmare. All 36 boards had 1 LED on backwards and one (5-pin! 🙄 ) linear regulator also flipped 180 degrees. Then there were assorted other problems, including about half of the boards have a soft short between power and ground that I haven't figured out yet. So having them all done by the June launch is pretty much out. Rather than wait to see when these boards can be reliably and verifiably fixed, I'm going to get some new boards and parts (my wallet says ouch) and send it to the faster, high-quality and much-more-expensive assembler I used for the first batch. So it's looking like about a week for the board, 1-2 weeks for the assembly, and about a week for me to finish them from there. I'll probably come to the June launch with a couple more V2 units that I'll have reworked myself for my own testing, but no promises that there will be any that I'd be willing to call production units for purposes of record attempts.
I'm in no hurry on the new unit, I'll be here playing with the builds.....
hold off for me until you have a standard production unit.
Warren
Latest Post: Hello World Our newest member: manuelageach965 Recent Posts Unread Posts
