Jolly Logic Altimeter Two Charging

The Rocketry Forum

Help Support The Rocketry Forum:

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

ClusterNut

Well-Known Member
Joined
Aug 31, 2010
Messages
350
Reaction score
0
I just received an Altimeter Two from Jolly Logic via Amazon. I really like my Altimeter One and decided to upgrade. I charged it for several hours, leaving it connected even after the green LED came on. But when I turned it on, it said 85% charged. I charged it some more and still 85%. I charged it with my computer and with a wall plug adapter. I don't think it is losing the charge but I will know for sure when I fly with it next weekend. Has anyone had this experience with an Altimeter Two? I'm not very concerned if it just a quirk.
 
I am a new Altimeter 2 user myself, having only bought one less than a month ago. I too have observed strange status messages from the battery. The charging light goes green, indicating a full charge, but the display might say much less than that (80%?). Then I'll cycle through the menu display, and it might say 100%. But as I continue going through menu options, it will suddenly drop to something like 45%. My hope is it just needs a few charge cycles to get broken in. Guess we'll see...
 
This is what I am seeing as well. In fact, it went from 85 to 87% just sitting on the table overnight. I plan to fly it in a rocket that I flew with my Altimeter One and see how it compares for altitude reporting.
 
I've never had an AltimeterOne, so I don't know how it compares in battery behavior.
 
When you see a charge that says 85%, is it still plugged in?
I should probably put a note in the manual about that--it can't really tell its own charge until it is unplugged. When it is plugged in, the charger takes control of the battery voltage, and pushes it around in ways the software has a hard time interpreting properly.

If it shows 85% after a full charge and after cycling through the flight displays on its own, that's not normal. Lemme know if that's the case, please.
 
It shows 85% unplugged. I'm flying tomorrow and plan to use it in a rocket that I have flown with an Altimeter One. I can see if I get comparable altitude readings. I'll run the battery down some and recharge again. Maybe a charge cycle or two will help. I'll let you know what happens. These are cool little altimeters and I have had great results with my Altimeter One.
 
ClusterNut,
Thanks for the kind words.

It's kind of a head-scratcher why you'd see 85% on a full charge for an altimeter that's not attached and is started from an off position.
Let me know what kind of field battery life you see. The new batteries (which are replaceable, larger, and more reliable than before) perform quite well usually.
By comparison, I found myself "babying" the previous generation; I'd charge them up the night before every launch (running the risk of getting to the field and realizing they were still in the charger). But this new generation I charge rarely. They just seem to work right out of the field box, and they charge more rapidly.

I bought a cheap mobile phone charger battery from Fry's electronics (the kind of battery you charge up and then use to charge your phone later). It is a small one, but can charge an altimeter many times, and very quickly. It's in my field box as a "just in case." It has the advantage of using the same cable that ships with your altimeter. So the two of them can share the same cable for recharging themselves and recharging the altimeter. Handy.

I thought I'd miss the built-in USB connector of the original design. But given how universal the micro-B USB is, it's not really an issue (in my opinion). Open to comments on that.

en-INTL_L_Nokia_DC-19_Portable_USB_Charger_Cyan_C9F-00082_mnco.jpg
 
When you see a charge that says 85%, is it still plugged in?
I should probably put a note in the manual about that--it can't really tell its own charge until it is unplugged. When it is plugged in, the charger takes control of the battery voltage, and pushes it around in ways the software has a hard time interpreting properly.

If it shows 85% after a full charge and after cycling through the flight displays on its own, that's not normal. Lemme know if that's the case, please.

When I first saw this, it was right after unplugging. It was actually the first time I'd charged it and I disconnected it probably within a couple minutes of going green. Since then, I put in on a charger for about a week. When I took it off and checked, the charge read 100%.

Nevertheless, I'm still seeing odd results when I scroll through the menu. The charge level seems to report either 100% or 45% and bounces between these two values. Any idea what is causing that? Mine is a version 3.9 unit.
 
Nevertheless, I'm still seeing odd results when I scroll through the menu. The charge level seems to report either 100% or 45% and bounces between these two values. Any idea what is causing that? Mine is a version 3.9 unit.

Right before final release, I took out some smoothing software that would have kept the jumps from happening. I may need to put some back. There's nothing wrong with your unit. You can think about it like a laptop when you adjust the screen brightness and the remaining battery time jumps around. In this case, the high number is more correct ( the low one was taken during a high current event, like accessing the flash drive). Hope that makes sense. It's not failing, it's just changing its mind. :)
 
That explains that! I was wondering. I've flown a new-generation AltimeterTwo a couple of times but saw those wide battery status fluctuations and wondered what was up. Now I know.
 
Thanks for solving the mystery! Gives me peace of mind that I don't have a defective unit.
 
I flew this afternoon with a rocket I have flown with an Altimeter One in the past. The data were a little lower than the OR projections but this is in line with what I saw with the Altimeter One altitude results. The rocket has a bit more drag than the sim. The power status was 85% before the flight and 100% after. It will be interesting to see what happens the next time I charge it. I'm not concerned since I always charge up before I fly anyway.

The post apogee data were strange. The measured coast time (8.2 sec) was close to my delay setting (8 sec) and the apogee-to-ejection turned out negative (-8.3). The ejection happened just about at apogee and that would explain the negative time. But the ejection altitude was 107 instead of about 1100 and the descent rate was 0. Maybe this was due to the ejection happening just before apogee? Or could it be the way I mounted the unit? I just hooked to the base of the nose cone inside the payload compartment. Maybe some padding is necessary?

I like this unit. :D
 
I flew this afternoon with a rocket I have flown with an Altimeter One in the past. The data were a little lower than the OR projections but this is in line with what I saw with the Altimeter One altitude results. The rocket has a bit more drag than the sim. The power status was 85% before the flight and 100% after. It will be interesting to see what happens the next time I charge it. I'm not concerned since I always charge up before I fly anyway.

The post apogee data were strange. The measured coast time (8.2 sec) was close to my delay setting (8 sec) and the apogee-to-ejection turned out negative (-8.3). The ejection happened just about at apogee and that would explain the negative time. But the ejection altitude was 107 instead of about 1100 and the descent rate was 0. Maybe this was due to the ejection happening just before apogee? Or could it be the way I mounted the unit? I just hooked to the base of the nose cone inside the payload compartment. Maybe some padding is necessary?

I like this unit. :D

I've seen this before. If the rocket abruptly decelerates after burnout, it can be mistaken for ejection. Believe it or not, some rockets (especially fatter ones) can decel at 2-3Gs once the motor burns out. Maybe sometimes it's a sputter or a slow-down shimmy waggle, too. Anyhow, AltimeterTwo thinks ejection happened right after burnout, then it calculated "coast to apogee" (which is really "burnout to apogee") as 8.2 and "apogee to ejection" as -8.3. The negative 8.3 means it thinks burnout was ejection. Whenever you get two figures roughly the negative of each other, that's what happened. It's a weakness in the logic that I have a fix for.

In case anyone is interested, the fix involves the altimeter (which, remember, can be mounted in any direction) detecting which direction the launch occurs in, then *ignoring* a strong subsequent acceleration in the opposing vector. Since the accelerometer has three axes, it can do all of this with 3D vectors. I've detected this issue in my own flights once or twice (I like low-and-slow rockets), but I've been reticent to implement it because:

1. Any change needs lots of testing
2. I am hard at working finishing AltimeterThree and my flying time has been limited.

Excuses, excuses...
 
I've seen this before. If the rocket abruptly decelerates after burnout, it can be mistaken for ejection.

What if the delay was too short by a couple of seconds? Would that have a similar effect? Or if the altimeter bounced around? I was thinking of putting a collar of some sort around it the would let breathe but wouldn't let it swing too freely on it's connection.
 
If I remember correctly, mine acted a little goofy at first too. It "settled down" and worked fine after a flight or two. It always worked fine, just had some odd battery readings.
 
What if the delay was too short by a couple of seconds? Would that have a similar effect? Or if the altimeter bounced around? I was thinking of putting a collar of some sort around it the would let breathe but wouldn't let it swing too freely on it's connection.

In that case you'd see readings like C2Ap = 8 secs, Ap2Ej = -2 secs. Or almost. Remember, you can't always tell how early you popped because once you pop, stuff slows *way* down usually. For instance, you might pop 5 seconds earlier than a simulated flight, but it won't coast for 5 seconds because ejection breaks the rocket up and the parachute usually pops out from a couple of tenths of a second to a couple of seconds later. So a very common Ap2Ej reading for small rockets is -0.2 seconds. Pop. Stop.

Make sense?
 
What if the delay was too short by a couple of seconds? Would that have a similar effect? Or if the altimeter bounced around? I was thinking of putting a collar of some sort around it the would let breathe but wouldn't let it swing too freely on it's connection.

I've heard people wondering about the altimeter swinging around, but I've never seen results that indicated that a loose mounting had any adverse effect. I've flown big rockets with 5 altimeters hanging from the nose cone and gotten agreement from them with 5 more that were rigidly mounted in the payload section.
 
In that case you'd see readings like C2Ap = 8 secs, Ap2Ej = -2 secs. Or almost. Remember, you can't always tell how early you popped because once you pop, stuff slows *way* down usually. For instance, you might pop 5 seconds earlier than a simulated flight, but it won't coast for 5 seconds because ejection breaks the rocket up and the parachute usually pops out from a couple of tenths of a second to a couple of seconds later. So a very common Ap2Ej reading for small rockets is -0.2 seconds. Pop. Stop.

Make sense?

I am curious about one more thing. What should I expect to see in a two stage rocket? I am guessing that the staging event could confuse things. I only stage BP motors, by the way.
 
Yes, staging does confuse it.....there's a note in the instructions about that I think.

The apogee value is still good but the calculations based on accelerometer data do get confused in my experience.
 
Yep, Bernard's right. Two-stagers are tough. If the gap between stages is short enough (less than a second, I think), the burn time can be for both. If not, the second burn may look like an ejection, throwing everything off. I'm not sure I can completely fix the algorithm for multi-stagers soon. It's possible (since the trajectory continues), but probably the first good solution will be the 'Three, which logs everything on a graph that you can study.
 
Yep, Bernard's right. Two-stagers are tough. If the gap between stages is short enough (less than a second, I think), the burn time can be for both. If not, the second burn may look like an ejection, throwing everything off. I'm not sure I can completely fix the algorithm for multi-stagers soon. It's possible (since the trajectory continues), but probably the first good solution will be the 'Three, which logs everything on a graph that you can study.

That's what I expected. I am sure a real time analysis with this sort of flight profile is not something for this type of device. Logging the raw data for analysis would be great.
 
I've seen this before. If the rocket abruptly decelerates after burnout, it can be mistaken for ejection. Believe it or not, some rockets (especially fatter ones) can decel at 2-3Gs once the motor burns out. Maybe sometimes it's a sputter or a slow-down shimmy waggle, too. Anyhow, AltimeterTwo thinks ejection happened right after burnout, then it calculated "coast to apogee" (which is really "burnout to apogee") as 8.2 and "apogee to ejection" as -8.3. The negative 8.3 means it thinks burnout was ejection. Whenever you get two figures roughly the negative of each other, that's what happened. It's a weakness in the logic that I have a fix for.

In case anyone is interested, the fix involves the altimeter (which, remember, can be mounted in any direction) detecting which direction the launch occurs in, then *ignoring* a strong subsequent acceleration in the opposing vector. Since the accelerometer has three axes, it can do all of this with 3D vectors. I've detected this issue in my own flights once or twice (I like low-and-slow rockets), but I've been reticent to implement it because:

1. Any change needs lots of testing
2. I am hard at working finishing AltimeterThree and my flying time has been limited.

Excuses, excuses...

I saw this same thing on the latest flight of my crayon bank. I have some other funny numbers on the flight as well, but that's mostly due to the nosecone/e-bay and chute separating from the rest of the rocket at deployment and drifting some distance away. (For those that know Moffett, it drifted from the launch area all the way back to the parking lot we use over by base-ops.)

I've got the Altimeter2 with the 3.8 firmware, which I'm planning to send in for the metric bug update. I'd also be willing to help test the fix for the burnout/ejection detection logic.
 
I'd also be willing to help test the fix for the burnout/ejection detection logic.

Robert,
I'll probably take you up on the testing. When you send in your 'Two for updating, I'll send you a test version 'Two as well. That would be a big help, since you fly more often than I get to.
 
Robert,
I'll probably take you up on the testing. When you send in your 'Two for updating, I'll send you a test version 'Two as well. That would be a big help, since you fly more often than I get to.

I'll have it out in the mail to you tomorrow, (I need to copy the flight data off still.)

I'll fly both altimeters multiple times at the next Moffett launch. I'll even try to recreate the flight conditions that gave me the funny readings last time, sans the shock-cord separation. Let me know if there's any particular format you'd like the results in. :)
 
Robert,
Do you own a smartphone or tablet? My first preference is to run an AltimeterThree in the same flight, so that we can capture all the flight data in an easily-sharable format. But it's okay if you don't. The 'Three is the same size as the new 'Two (in fact, that's why the 'Two grew.)
--John
 
John, I have access to the following:

iPhone 4S (IOS 7.1.2)
Galaxy S3 (Android 4.4.2)
iPhone 3GS (IOS 6 something)
1st Gen iPad 3G (IOS 5 something)


Any (or all) could be brought to the launch. Guaranteed to have the 4S on me at least.
 
Last edited:
I'd prefer to use the iPhone, since the Galaxy is technically a "work phone" provided by my employer and I dislike adding personal stuff to it.

-Robert
 
Back
Top