AltimeterThree for Android Released

The Rocketry Forum

Help Support The Rocketry Forum:

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

John Beans

Founder, Jolly Logic
TRF Supporter
Joined
Jun 4, 2010
Messages
888
Reaction score
352
AndroidGetsA3.png

AltimeterThree is now available for owners of Android phones and tablets, as well as Apple iOS.

You can get the free app from either Google Play or shortly from Amazon Apps, and I'd advise you to install it and play around with it (to make sure your device is compatible) before purchasing the altimeter itself.

If you have any direct questions or feedback (or cool flight graphs, love to see them) I'm interested and available at [email protected] .

From Android, click: https://play.google.com/store/apps/details?id=com.jollylogic.altimeterthree


AndroidPlayStore.png amazon-apps-store-us-black.png
 
Last edited:
Cool!

I tried to get out to test the Android version this weekend but the time, weather, and launch site availability didn't all happen at once... :(

Our club has a launch this coming Saturday, and WAC has one on Sunday....and right now at least the forecast is for the weather to cooperate. So....opportunities at least.
 
I'm going to try this out on my Galaxy S3. I guess that means I need to go charge that battery...
 
By the way, I went on Amazon awhile back to pick up another Android device for testing. I got a used (but like new) Moto G phone for $50. I'm not activating it, just using it as a WiFi/Bluetooth device. It works great. Fifty bucks!
 
Downloaded the app for Android and it seems compatible with my Galaxy S4 phone.
 
By the way, I went on Amazon awhile back to pick up another Android device for testing. I got a used (but like new) Moto G phone for $50. I'm not activating it, just using it as a WiFi/Bluetooth device. It works great. Fifty bucks!
That's a great idea to get what is effectively a very cheap pocket-sized android tablet. The GSM phones use a SIM card and from what I've read in various places, some phones won't allow you to do anything whatsoever until the SIM card is inserted and activated. Was your phone activated by the previous owner and the contract or pay-as-you-go time expired or was it never activated? Is it an unlocked version? I ask because I see some like-new returned phones that were never activated for sale.
 
Was your phone activated by the previous owner and the contract or pay-as-you-go time expired or was it never activated? Is it an unlocked version? I ask because I see some like-new returned phones that were never activated for sale.

You know, good point: this was a Verizon pre-paid phone, and I was careful to make sure that it was still "activatable." There's a screen that comes up when you first turn it on, you just swipe it away. From that point on, it's a WiFi phone.
 
You know, good point: this was a Verizon pre-paid phone, and I was careful to make sure that it was still "activatable." There's a screen that comes up when you first turn it on, you just swipe it away. From that point on, it's a WiFi phone.
Ah, Verizon uses the CDMA mode of the phone, not GSM, so the SIM card is not used. Since yours obviously works as intended without a contract, the safest bet would be to buy used versions that were Verizon pre-paid. Sprint and U.S. Cellular also use the CDMA mode, so they might also be safe options:

CDMA vs. GSM: What's the Difference?

https://www.pcmag.com/article2/0,2817,2407896,00.asp
 
Last edited:
I got a Verizon Droid Incredible 2 is CDMA Verizon's US networks but is also SIM card capable to make it compatible with GSM networks outside the US.

Bob
 
John , I watched your excellent tech talk at the 2013 NARCON on YouTube last year and this one at the 2014 NARCON today:

[video=youtube;YGlUtlNkdWY]https://www.youtube.com/watch?v=YGlUtlNkdWY[/video]

I'm most interested, by far, in the ChuteLock as it eliminates the safety and legal issues with using BP or Pyrodex. The reaction of the crowd to your NARCON 2014 comment "I'm not sure this is going to be all that popular" indicates others are, too. BTW, you failed to answer their "approximate availability date" question.

Also, about the timer mode pull tab, since you have a barometer chip onboard, couldn't the ejection event instead be sensed by the pressure spike caused by the 'chute's ejection charge and/or by a phototransistor/diode?

Also, really like the CasualNet idea.

EDIT: Thought of the quadcoptor idea myself. On your comment about programmable waypoints and flying out of radio range, that's a no-no according to the FAA as the craft must be within visual range and under the pilot's real-time radio control at all times:

https://www.rcgroups.com/forums/showthread.php?t=2192501

The question of whether visual aids like binocs can be used to comply with the "within visual range" rule still hasn't been adequately answered. Clarification may be pending. Radio range won't be an issue for visual range flying.

Of course, this makes excellent sites like DIY Drones and the many FPV threads at RC Groups dealing with beyond visual range FPV/waypoint flying N/A for US flyers, unfortunately.
 
Last edited:
I'm most interested, by far, in the ChuteLock... The reaction of the crowd to your NARCON 2014 comment "I'm not sure this is going to be all that popular" indicates others are, too. BTW, you failed to answer their "approximate availability date" question.

We should probably start a separate thread on the upcoming parachute release product, since people not interested in AltimeterThree may want to hear more about it. I'm in the lab taking a break from design work on it right now, with the CAD program open and tiny parts laid out around me. This is a product that has a tremendous amount of personal appeal to me: a product I'd use every flight, that I've wanted for years. I think it's "transformative," in that it would advance the sport in several positive ways (let us better use our smaller fields, and potentially keep more rockets out of trees). Dual Deployment for Everyone. And I love working on it because the blend of mechanical and electrical engineering that it requires is my favorite combination of things to spend time on.

We already see failed deployments with just a simple parachute; it's inevitable that this would add a *potential* source or two of failure. If it's designed well, the product should invite you to use it correctly, and "just work," even if you don't pay much attention to the instructions. By the way, the current design iteration looks rather different, since I came up with a more universal and practical way to secure and release both small and large chutes. More on that later. And of course it has to work well, and be affordable, which are non-trivial.

With regards to the timing feature you mention, I may strip that out of the first version to lower costs and simplify. It was more for drones and low-flying aircraft anyway.

On your comment about programmable waypoints and flying out of radio range [for the upcoming locator product], that's a no-no according to the FAA as the craft must be within visual range and under the pilot's real-time radio control at all times:

Yeah, that's too bad the rules are heading that direction, at least for this purpose (it is a good idea for safety). The use of binoculars seems reasonable to me (the drone pilot can ensure that there are no other visible risks), and that would give us the mile or two search pattern that would be needed for most non-max-altitude flights. Even within sight range, the ability to program in waypoints and have it search a grid is really cool to me still. I think part of the mission of most clubs should be to set up tracking points (a locator product on a pole stuck in the ground) and see that there's a drone pilot at each launch to carry a roving locator. I think you'll find that clubs already have a number of multirotor enthusiasts already. At LUNAR high power flights in northern California, we've already had launch days with multiple drones buzzing around.

By the way, right now the smallest tracker I'm designing (there will be multiple versions) has dimensions of about 22mm x 50mm x 12mm, or roughly the size of a wide AltimeterOne). You'll be able to look at your mobile phone and see the distance and direction to your rocket, or on a map if you've got network access.
 
We should probably start a separate thread on the upcoming parachute release product, since people not interested in AltimeterThree may want to hear more about it. I'm in the lab taking a break from design work on it right now, with the CAD program open and tiny parts laid out around me. This is a product that has a tremendous amount of personal appeal to me: a product I'd use every flight, that I've wanted for years. I think it's "transformative," in that it would advance the sport in several positive ways (let us better use our smaller fields, and potentially keep more rockets out of trees). Dual Deployment for Everyone. And I love working on it because the blend of mechanical and electrical engineering that it requires is my favorite combination of things to spend time on.

We already see failed deployments with just a simple parachute; it's inevitable that this would add a *potential* source or two of failure. If it's designed well, the product should invite you to use it correctly, and "just work," even if you don't pay much attention to the instructions. By the way, the current design iteration looks rather different, since I came up with a more universal and practical way to secure and release both small and large chutes. More on that later. And of course it has to work well, and be affordable, which are non-trivial.
Besides the "dual deployment for nearly anything" advantage allowing gentler landings using larger 'chutes that would cause unacceptable drift if not deployed at lower altitudes, I believe just the anti-zipper effect of delayed deployment is incredibly valuable for motor delay based deployments, those motor delays being in too many cases highly "approximate" (regardless of what the manufacturer supplied motor certification test results indicate).
 
I believe just the anti-zipper effect of delayed deployment is incredibly valuable for motor delay based deployments, those motor delays being in too many cases highly "approximate" (regardless of what the manufacturer supplied motor certification test results indicate).

Agreed.

Of course, one limitation to only solving the second part of the dual deployment sequence (the parachute release, but not the apogee ejection which comes first) electrically is that it will most appeal to rockets with motor ejection. That limits usage to about a K motor I suppose. That's still pretty big for most folks (L2).

Of course, you could still use an altimeter and a charge to eject, then use this upcoming product to release down low, but that's not really a simplification if you've already got the deployment altimeter and the gunpowder sitting around. Though I suppose if it turns out to be significantly more reliable than a charge-based secondary deployment, that would be good. In case you're wondering, it will be build so that you can use two of them together for a redundant configuration. Turn them on, make sure they are both set to the right altitude, and you're ready. If either triggers, you parachute deploys.

One thing I'm wondering is what altitudes to allow. It's one of those issues where it totally depends what the rocket weighs and how big the parachute is and how hard the wind is blowing. While I don't want people to get angry when they see some big heavy rocket with a teeny parachute deploy at 200 feet and hit a car near the line going too fast, I also don't want someone to say they lost their Estes Executioner (and this product) because it opened at the lowest allowable altitude and still floated away. No matter what guidance I give, someone's going to think, "lower is better... why not open as low as possible?" But then they may fail to really figure out what is best in their case. I tend to think that it is the rocketeer's (and partly the LSO's) responsibility to use reasonable settings. But I know that some folks will want me to design this so it CAN'T be misused...
 
Of course, one limitation to only solving the second part of the dual deployment sequence (the parachute release, but not the apogee ejection which comes first) electrically is that it will most appeal to rockets with motor ejection. That limits usage to about a K motor I suppose. That's still pretty big for most folks (L2).

Good enough for most, I suspect.

Of course, you could still use an altimeter and a charge to eject, then use this upcoming product to release down low, but that's not really a simplification if you've already got the deployment altimeter and the gunpowder sitting around.

Aye, but there's the rub! Whether or not you have a LEUP, the way I read the regs, the sale of both BP and Pyrodex is intended for use in antique or antique style firearms only, and getting away with any other use is dependent upon the mood and reg knowledge of the BATFE agent who might find you using it for an ejection charge. That's why I elsewhere here suggested completely seriously, that the powder cup for ejection charges should be a tiny aluminum civil war mortar. That's an "antique firearm" miniature reproduction and where that firearm is located and how it's recreationally used isn't specified or mandated in the regs.

A non-pyro delayed deployment device like the ChuteLock will completely eliminate both the legal gray area and safety issues involved with BP or Pyrodex ejection charges.

One thing I'm wondering is what altitudes to allow. It's one of those issues where it totally depends what the rocket weighs and how big the parachute is and how hard the wind is blowing. While I don't want people to get angry when they see some big heavy rocket with a teeny parachute deploy at 200 feet and hit a car near the line going too fast, I also don't want someone to say they lost their Estes Executioner (and this product) because it opened at the lowest allowable altitude and still floated away. No matter what guidance I give, someone's going to think, "lower is better... why not open as low as possible?" But then they may fail to really figure out what is best in their case. I tend to think that it is the rocketeer's (and partly the LSO's) responsibility to use reasonable settings. But I know that some folks will want me to design this so it CAN'T be misused...
I don't see how it could possibly be designed so that it can't be misused. Perhaps allow the lowest altitude of deployment that can be safely allowed (200ft?) based upon barometric sensor accuracy (considering ambient temperature effects) and then put some conservative table in the instructions that lists rocket weight vs. minimum allowable deployment altitude, basing that table upon a discussion of that topic by experienced low/mid/high power flyers on this site in a ChuteLock thread?
 
Last edited:
Could this be moved to a separate thread? I'm certainly interested, specifically for a rocket that doesn't have room for proper DD so I've been working on a hot-wire cable cutter (almost there I think, may possibly test it at tomorrow's launch, but I'd appreciate alternatives as well). But I've also been thinking about a spring-loaded ejection system for a Minie-Magg (to avoid needing BP even on pushing the 'chute out of the airframe), it would be really neat if something like your ChuteLock idea could help there also (to hold the spring 'piston' in place until it's time to release).
 
Could this be moved to a separate thread? I'm certainly interested, specifically for a rocket that doesn't have room for proper DD so I've been working on a hot-wire cable cutter (almost there I think, may possibly test it at tomorrow's launch, but I'd appreciate alternatives as well). But I've also been thinking about a spring-loaded ejection system for a Minie-Magg (to avoid needing BP even on pushing the 'chute out of the airframe), it would be really neat if something like your ChuteLock idea could help there also (to hold the spring 'piston' in place until it's time to release).

Will,
As I mentioned, the product would release the chute at altitude, but you'd need motor ejection to get it out first (there's always room for motor eject). Ultimately, I want to handle the ejection electronically, too. But that will have to wait.

Re-purposing what I'm developing wouldn't be a good idea for the ejection part. I mean, you could try, but I doubt it would be very easy or reliable. You'd be better off with a deployment altimeter and a servo board for that. I can tell that you and I think alike about dual deployment and the ultimate end goal, but this first product won't do it all. Though I can't wait to fly it.
 
So, I don't have an actual AltimeterThree yet, but I've been playing with the Android version of the software, and, overall, I'm really digging it.

One dumb question/suggestion, though: is there any way to export the files, specifically the spreadsheet without actually going through the steps of "sharing" it via e-mail or whatever.

In other words, is it/could it be possible to export the spreadsheet to the handheld device's filesystem, then just copy it via USB or WiFi when you get back to your computer?

To be clear, although I find the "sharing" process a few more steps than I would prefer, it's definitely not a deal-breaker; I'll be ordering at least two 'Threes in the next couple of months.

Thanks
 
could it be possible to export the spreadsheet to the handheld device's filesystem, then just copy it via USB or WiFi when you get back to your computer?

I'm probably biased by the fact that over the last 5 years or so I have begun to rely heavily on email as a way to move files around (pictures, code files, PDFs), and enjoy its cloud-based nature (if it's in email, you've always got a backup copy, even after you "delete" it). It's not hard to write code that would save the flight to local files, in fact, every file (spreadsheet, image, table) actually is already saved to local app (not user-accessible) storage as an intermediate step before being shared. I'll need to think about that idea a bit. You're not the only one that wants to get the files onto their PC. In fact, one of the top requests is for a desktop version of the app.

Step one of that process is to turn on the cloud component of the product that I've already built. Right now, new firmware images already start in the cloud and the app looks for them when it starts up. That same plumbing can allow you to tag certain flights (or all of them) as being worthy of being saved in the cloud. They'll get auto-magically copied to the cloud, and if you have another device (tablet, in the future PC) the flights will automatically appear in the app there--with no need to do anything else. In other words, you could come back from a flight day to find all of your flights already on your computer.

The only reason I haven't already rolled that out is the account management part of it needs to be very thoughtful. Some people aren't going to want to mess with an "account" (with user name and password), but that would be required for this. Only you should be able to see/delete your flights. That requires security.
 
The only reason I haven't already rolled that out is the account management part of it needs to be very thoughtful. Some people aren't going to want to mess with an "account" (with user name and password), but that would be required for this. Only you should be able to see/delete your flights. That requires security.
As an ex-developer and current DBA, I understand completely. Like I said, it's not a dealbreaker at all, just that I see (for myself, at least) a couple of potential use-cases:

  • No Internet connection available; I might have a WiFi-only tablet, and have my laptop out in the field with me, and want to get into the spreadsheet ... Corollary with this is maybe my field has crappy/no 4g coverage.
  • Data usage: looks like the package is only ~300k, so probably not a big deal, but the days of unlimited data are over for most of us (and, certainly, one could choose just the spreadsheet to reduce usage)
Ultimately, though, for me at least, what it boils down to is that I'm lazy. After I tap the "Create email" button, I have to wait for my phone to fire up my selector for which app to use. Then I have to wait for the app to start, then I have to find the e-mail address to send it to, then, finally, I can hit "Send". Then, of course, I have to go to my e-mail app on my PC and download them all.

I have a short attention span (roughly akin to that of a goldfish, or a large dog. What were we talking about? SQUIRREL! :wink:). I like the idea of just tapping "Save to Filesystem", or "Save to Google Drive". If I manage to make several flights in a day, then all I have to do is plug in via USB or WiFi and fire up a file-manager, or hit my Google drive from my PC, and, voila, I've got all of my flights for the day in one easy spot.

Everyone has their workflow with which they're comfortable, and I admit that mine may not be for everyone. Just wanted to get my $0.02 into the suggestion box. As for working with the spreadsheet on a PC, yeah, that's a big draw for me.

Again, it looks like a great product, and I'm really looking forward to getting mine to start playing with.

Thanks again
Adrien
 
Back
Top