Isn't that GPS only and not a combo unit?It's been done, just not sure how well it works for rocketry, or whether it's legal in the US.
https://bmks.co.uk/products/bmk-sky...95983&pr_ref_pid=7075076833487&pr_seq=uniform
Isn't that GPS only and not a combo unit?It's been done, just not sure how well it works for rocketry, or whether it's legal in the US.
https://bmks.co.uk/products/bmk-sky...95983&pr_ref_pid=7075076833487&pr_seq=uniform
I wondered that, but it appears that it does also have a barometric altimeter and that altitude data can be downloaded post flight: https://cdn.shopify.com/s/files/1/0594/0959/6623/files/BMK_SkyLink_434_22_09_2023.pdf?v=1695394791Isn't that GPS only and not a combo unit?
Based on what Cris Erving sells (and how it differs outside the US) I expect this little goodie is not legal for US use. As I recall he mentioned that in the US, that 434 mHz area is used for cellular communication, and the frequencies his US trackers/telemetry devices use are used for cell phones in Europe/UK. I think that's what he told me/us....It's been done, just not sure how well it works for rocketry, or whether it's legal in the US.
https://bmks.co.uk/products/bmk-sky...95983&pr_ref_pid=7075076833487&pr_seq=uniform
What kind of barometric messiness are you referencing around recovery deployment? I record small fluctuations from the ejection charge and shock cord oscillations, but nothing messy. I don't use any rocket specific filters with my DIY projects, other than high-speed data collection at 80Hz.I wondered that, but it appears that it does also have a barometric altimeter and that altitude data can be downloaded post flight: https://cdn.shopify.com/s/files/1/0594/0959/6623/files/BMK_SkyLink_434_22_09_2023.pdf?v=1695394791
However there is no accelerometer, and I don't see any evidence of any sort of rocket-specific filtering on the altitude data, which means that the messiness that happens around recovery deployment will likely not be handled well. Or that's what I would expect.
John --What kind of barometric messiness are you referencing around recovery deployment? I record small fluctuations from the ejection charge and shock cord oscillations, but nothing messy. I don't use any rocket specific filters with my DIY projects, other than high-speed data collection at 80Hz.
I've heard the same thing with competition fliers. I have never attempted such a mounting location, but I can see it producing large over pressure fluctuations plus damage to the sensor. I record a venturi induced under-pressure event before the ejection charge over pressure cloud reaches the barometric sensor.John --
I wondered about the messiness as well but then I recalled reading here on TRF that competition fliers sometimes mount their altimeters to the shock cord ...
Maybe ?
-- kjh
When the altimeter just has some wadding around it and placed the the body tube with the parachute; it sees pressure waves from the, powder burn, ejection event, nose separation, at end of cord, as parachute opens, etc.What kind of barometric messiness are you referencing around recovery deployment?
Well....several things. Barometric sensors are sensitive to being shaken around. Almost all deployment events involve some mechanical chaos even if they are perfectly timed. In competition, especially pure altitude competition, the ejections are almost always too early, so the mechanical chaos is heightened.What kind of barometric messiness are you referencing around recovery deployment? I record small fluctuations from the ejection charge and shock cord oscillations, but nothing messy. I don't use any rocket specific filters with my DIY projects, other than high-speed data collection at 80Hz.
Pop on over. We'll have room. Beachcomber Resort, Ocean Shores, Washington.Bernard, outstanding! Are you sure you don't want to take me along to the beach so we can discuss this further.
We had a couple during the WSMC whose LEDs stopped working, but they still operated fine. We held them out until we had to use them, which happened on S2/P day when both Jrs. and Srs. were doing the event the same time. We did also have one come back that was bent enough that trying to straighten pins didn't end well. They are tough little buggers. I'm sure their being essentially potted in epoxy everywhere they can be helps that.The Adrels are also extremely robust. You will lose them before they go bad. Honestly, I've probably owned 40+ over the last 15 years and have only had a few fail, mostly because of bent pins. Only one that I can recall going bad with good pins. Could that have been from ejection damage, who knows? I even fly some of them in body tubes without wadding. The streamer material I use, aluminized kapton, is heat insensitive so that acts as wadding in many of my flights. Altimeter sits just above the streamer, open in the tube. Sometimes actually folded battery next to altimeter, in a 13mm nosecone. Ability to read well and reusability not an issue. I've also actually had one run over by a truck with no ill effect so when I say they are robust, I'm not kidding.
This is why I'm also skeptical about the tiny GPS trackers/altimeters we've been discussing a little further up in this thread being suitable for rocketry uses, at least from the altimetry perspective. They could be super trackers.To to get back to Bernard's main point, for rocketry altimeters demonstrating the ability to effectively deal with ejection spikes is very important. As far as we can tell the new Serbian altimeters we will be using were tested only in drones. Not very comforting.
Thanks for the information. The raw unfiltered data and smoothed data gives me insight to the filtering methods being used. I don't agree with the exposure of barometric sensors to ejection charge gases, unless the sensor has a gel transfer medium. My opinion as a fluidics engineer in semiconductor manufacturing (retired).Well....several things. Barometric sensors are sensitive to being shaken around. Almost all deployment events involve some mechanical chaos even if they are perfectly timed. In competition, especially pure altitude competition, the ejections are almost always too early, so the mechanical chaos is heightened.
Also, not all ejections are timed right in other situations...and again there is a bunch going on for either early or late deployments.
Now...add in that the altimeter may not be in a separate compartment from the ejection gases. If the nose cone/payload section is the slightest bit reluctant to come off, then the place where it is will be pressurized above ambient for a brief moment. This shows up as a big downward spike in unfiltered altimeter data. Depending on the dynamics of the gases, the opposite can also occur (a slight vacuum is pulled, making the reported altitude spike upward).
Every commercial altimeter maker, at least those making altimeters where the actual reported altitude is the data we're looking for (as opposed to just trying to time a deployment charge) have some kind of filtering to smooth out/eliminate these sudden transients that come from sudden pressure or mechanical shocks.
I'll attach a few examples that I can locate quickly. I don't have time right now to do a bunch of searching. i'm trying to get ready for club launch tomorrow and a 10-day trip to the ocean the next day.
The first two compare an intentionally short-delay flight done while helping to get the FlightSketch devices contest accepted. It compares the latest FlightSketch firmware with a PerfectFlite Pnut. The two are plots I made with Magic Plot. NOTE that Perfectflite exports UNfiltered data only via their app. The next shot is what the PerfectFlite app itself shows for that flight — both raw and "smoothed" data. Note that the reported apogee (what a Pnut beeps or a Firefly blinks) is from the smoothed data.
Following that is an unfiltered set of data from an Adrel. Both of those spikes would be smoothed over similarly to what Perfectflite does when the "FILTR" is used. Using the filter is part of the process for recording flight scores at FAI competitions, including the 2023 World Spacemodeling Championships that were held near Austin, Texas, and at which my wife and I were half of the altimeter control team. Myself, @WillMarchant and Dan Wolf split the duty of reading and recording the data for each altitude flight at that event. (My wife had the fun duty of keeping track of who had which altimeter (by serial number) when and managing the "deposits" for the altimeters. I think she had the hardest job.)
The next two are from one flight using an Eggtimer ION, both the full flight and a closeup around apogee. @cerving is the only one whose device exports both unfiltered and filtered data (that I know of), which makes this comparison interesting to plot. His devices beep out and report via their WiFi interface the UNfiltered data, though he recently tweaked the ION firmware to change it to report filtered data....but as far as I know, he hasn't posted that version to his site.
The last is from an AltimeterThree. @John Beans' filter is quite good as one almost never sees any of the big spikes you see in the others with AltimeterThree.
You have calculated altitude transients in your flight data there as well as lots of craziness in accelerometer data around ejection. You even have several meter spikes in the data you posted when you asked the question. Contest altimeters typically aim for less than 1m error. Since that is the sort of altimeter this discussion has been about (mostly), dealing with even "small fluctuations" is important so that all contestants can trust the values.
In your Mongoose data above, at least the spikes at ejection in the altitude trace don't go above what I take to be the real apogee, which happened earlier. But you can't count on that happening. As I mentioned before, in pure altitude competition delays are almost invariably too short....which is why, I think, that Adrel created the device that NCR sells as the MaxDeploy. It's essentially an Adrel ALT-BMP that can fire a single pyro charge.
As for the penalty of 29 grams: that's a significant weight penalty for a model the size of the Nova Payloader (or the Mongoose, for that matter). Even with motor mass included that is ~30-40% over the liftoff mass it would have without one that heavy. This is why the Eggtimer ION is not a good candidate for small models if performance is to be maximized. An FS Comp is slightly less than 1g, and it looks like Adrian is headed in the same direction. An Adrel, with its standard 23 mAh cell is ~1.5g.
Craziness during this flight is the appropriate word. The Mongoose nose cone broke off at ~2.65 seconds. The Cd went from ~1.32 to ~2.13. Air flow over the vent port was highly turbulent. I'm amazed that it reached 540 feet with a concave nose plug. This is my first flight where I recovered data after a nose cone separation. Previous flights on other vehicles resulted in loss of data and flight computer. I need to study the spikes and run more simulations to understand the flow dynamics. The flight was only 3 weeks ago. The small fluctuations are not g load related. I've subjected Bosch barometric sensors to 900 g's without it affecting the output values.You have calculated altitude transients in your flight data there as well as lots of craziness in accelerometer data around ejection. You even have several meter spikes in the data you posted when you asked the question. Contest altimeters typically aim for less than 1m error. Since that is the sort of altimeter this discussion has been about (mostly), dealing with even "small fluctuations" is important so that all contestants can trust the values.
In your Mongoose data above, at least the spikes at ejection in the altitude trace don't go above what I take to be the real apogee, which happened earlier. But you can't count on that happening. As I mentioned before, in pure altitude competition delays are almost invariably too short....which is why, I think, that Adrel created the device that NCR sells as the MaxDeploy. It's essentially an Adrel ALT-BMP that can fire a single pyro charge.
As for the penalty of 29 grams: that's a significant weight penalty for a model the size of the Nova Payloader (or the Mongoose, for that matter). Even with motor mass included that is ~30-40% over the liftoff mass it would have without one that heavy. This is why the Eggtimer ION is not a good candidate for small models if performance is to be maximized. An FS Comp is slightly less than 1g, and it looks like Adrian is headed in the same direction. An Adrel, with its standard 23 mAh cell is ~1.5g.
Nice looking rocket. Light enough to loft with one of my 8mm motors. What size motor do you use, and altitude do you expect?View attachment 688498
Bernard, I know for many it's hard to conceive of models as small as we fly. The one above is 3.8 g, missing only altimeter and motor. The mass and position of the altimeter as far forward as possible in the nose and the overhang of the motor (yes, its measured before the motor is put in) is absolutely critical to stability in models this small. A 29 gram altimeter (equivalent to 7 of these models on the scale at once) would be a bit of a weight penalty.
That's pretty amazing — that the sensor took that many g's without perturbing the output. Perhaps with modern sensors, that portion of the explanation for the chaos in data around ejection is outdated.Craziness during this flight is the appropriate word. The Mongoose nose cone broke off at ~2.65 seconds. The Cd went from ~1.32 to ~2.13. Air flow over the vent port was highly turbulent. I'm amazed that it reached 540 feet with a concave nose plug. This is my first flight where I recovered data after a nose cone separation. Previous flights on other vehicles resulted in loss of data and flight computer. I need to study the spikes and run more simulations to understand the flow dynamics. The flight was only 3 weeks ago. The small fluctuations are not g load related. I've subjected Bosch barometric sensors to 900 g's without it affecting the output values.
Half a second is good. I've seen much more than that. The certification guidelines from the National Fire Protection Association are ±20% or ±1.5s, whichever is greater up to a total of 3 seconds. I have seen variations outside that tolerance in 18mm model rocket motors, both via accelerometer data in flight and in some static tests. Some motors and some batches are nicely consistent. Others, not so much. And aging motors, especially composite ones, can be worse.I agree that motor pyro delays can vary by ±10%. I recently experienced variations of ±450 ms for C6-5 motors from the same production lot. I'm updating my 18mm & 24mm flight computers with air bag deployment drivers for dual deployment experience.
I like it! I don't suppose you're going to market that are you?Attached is an altimeter project I was an advisor on a few years ago. Very similar to the Adrel, ~1.5g w/cell.
I tested 7 BMP280 sensors at 700 g's, two were further tested at 900 g's. One of the 700 g sensors did stop functioning a year later. One of the 900 g test sensors, I continue to use as a reference sensor. These tests were conducted in 2019. I had plans to test the TE Connectivity MS5611 sensor, but COVID, cost, and moving to Texas stopped the testing.That's pretty amazing — that the sensor took that many g's without perturbing the output. Perhaps with modern sensors, that portion of the explanation for the chaos in data around ejection is outdated.
I like it! I don't suppose you're going to market that are you?