I am working on code to interface with the companion port of a TeleMetrum.
So far I have not been too successful as I am having problems with my
hardware sending out the right bits. When I test my code i see multiple
setup messages and then after a few seconds the TeleMetrum stop sending out
companion packets. What is the expected packet sequence from the TeleMetrum
and under what criteria does it start periodically sending packets?
Also a slightly related question, is there a way for the TeleMetrum to play
out a flight over the companion interface? This would be great for treating
Thanks,
Jesse
Keith et al.
Thanks for the reply and advice. I appreciate your experience and system knowledge.
Casey and Drew pointed out that at over 100K the exact timing of apogee will not be that big of deal. There is not enough atmosphere to zipper the rocket.
It sounds like a good idea to have both a channel for <100K and another with longer delay for >100K. I typically use dual matches on the charges so if one altimeter fails, I have another firing the charge. Likewise, I always have backup charges.
The delay is another consideration that I did not take into account. It makes sense to give the rocket time for the accelerometers to detect the change in acceleration due to gravity. What about Drew's concern over the lack of integration over the three axis of accel? Can we assume that as the rocket arc's over the change in acceleration will become detectable and thus trigger apogee detection? Is there a set threshold for change in acceleration for the algorithm to detect apogee?
If we are fairly certain of apogee detection even in an off-vertical trajectory, then there may not be a real need for an EFU timer. Thoughts?
I have multiple APRS radios so it is enabled on all my TeleMegas. I like to have the audible radio beacon as a backup measure of confidence.
In 2013 at BALLS, I had the USC team set up a remote tracking station in the hills above the playa for the very reason of end-fire degradation. The rocket cato'd at 5,000 feet so RF degradation was the least of our problems then.
Thanks,Craig
-----Original Message-----
From: Keith Packard <keithp(a)keithp.com>
To: Craig Klimczak <compuvet(a)aol.com>; altusmetrum <altusmetrum(a)lists.gag.com>
Sent: Mon, Jun 24, 2019 10:37 pm
Subject: Re: [altusmetrum] BALLS Project
Craig Klimczak <compuvet(a)aol.com> writes:
> Are there any special considerations for setting up the TeleMega for
> flights to over 100,000 feet?
Yup, 100k' is where the baro sensor ends and you end up flying on accel
alone (really, it's just coasting at that point, so even the accel is
reading 0). This means that apogee determination is much less
precise. Fortunately, apogee determination is also much less important
as there's not much air to break things at speed.
What you want is to set a fairly long apogee delay when you're over
100k' (5-10 seconds or so, up to about 150k'), and to have a backup
channel programmed to fire at apogee, but only if under 100k'. You can
wire those to the same charges by matching the +/- terminals as
described in the manual.
> Are there any considerations for rockets exceeding Mach 3?
Not for the electronics; they don't care how fast you're going.
> What are the highest altitudes achieved with the TeleMega to date?
Not sure. We've got lots of EasyMega flights up to 150k' or so.
> I've flown this TeleMega to 35,000 feet with no problems. Is there an
> altitude where the performance of the TeleMega may be limited? Has
> anyone on this forum flown a TeleMege to 100,000 feet before. If so,
> how did it perform? Did you have any issues with tracking? Losing
> GPS lock?
You'll want to do some ground testing to measure the available telemetry
range.
At the default 38400 transmission rate, the signal is good to
about -105dBm. At 2400, it's good to about -120dBm. Each doubling of
distance takes about 6dB out of the signal. So, if you have a clear
space (hilltop to hilltop) to use, you can measure the signal there and
get a good estimate of the maximum range. Measure -70dBm at 1km and
you'll have 35dB, or nearly 6 doublings of available range (64km) at
38400 baud. All of our ground stations provide RSSI numbers to use for
this.
You should also consider enabling APRS and getting some good (yaesu or
kenwood) APRS-enabled HTs. APRS runs at 1200 baud, and although it's a
pretty terrible protocol in many ways, the quality of those receivers is
such that APRS has about the same range as our stuff running at 2400
baud.
Ground testing will uncover many potential issues which you can fix
before flying.
Note that a receiver located aft of the rocket will generally be in the
worst possible reception location. Not only are usually off the end of
the antenna where the signal is weakest, you're also behind a plume of
ionized gas, which blocks radio signals. Having another ground station
off to the side can improve the telemetry reception a lot. Having lots
of ground stations is generally a good idea anyways as things can happen
fast during flight and mistakes are easy to make.
GPS will lose lock during boost, but should re-acquire during coast. At
speed and altitude, it will stop reporting correct data due to COCOM
limits, but when you slow down, it will start again.
> Apogee detection?
See above.
--
-keith
Hi all,
I tried using ao-dumpflash on three EasyMegas.
On one, it worked seemingly ok, but on the other two a couple of "data
out of sync at 0x...x" messages appear, followed by an abort with an
"USB link timeout" error. The resulting dump files appear to contain
less than 200 Bytes of data (size on disk a few kB), compared to the 8
MB on the working EasyMega (size on disk 33MB).
Any Idea about the discrepancy or what I can do to avoid this?
Thanks,
Reinhard
Keith:
I think I have it now. I knew that gravity was a constant acceleration throughout the flight. My thinking was more wishful than understanding. I thought there was a magic algorithm.
Since acceleration plots on normal flights display chaotic acceleration data after separation, I found a data set for a rocket that had a failed apogee charge and a ballistic return. Unfortunately, it was not a TeleMega so I only have only one axis of acceleration that I can plot. Not surprising the acceleration plot did not change at apogee. It was a flat line until the main opened and zippered the rocket. Hence, the acceleration due to gravity is the same going up as it is going down (minus some drag).
Somehow, I thought with three axes you might be able to track the direction of acceleration looking for a vector change of acceleration. If lucky, you could see Z-axis acceleration change from negative 1 to positive 1. Even still, you are only working on a range of 0-1 if the zero on x and y don't include gravity. With rotation and tumbling possible, these axes would not be reliable either.
Either way, I learned a ton from this exchange. I understand how you approximate apogee by calculating velocity and and projecting the zero cross point for apogee. The algorithm for detecting apogee was really the crux of my questions.
Thanks for helping me get a deeper understanding.
I hope to see you again in Argonia.
Craig
Craig Klimczak <compuvet(a)aol.com> writes:
> Your're right. :-) I really don't understand what the
> accelerometers are reporting. I assumed that the accel would detect
> the de-acceleration as the rocket reached apogee, reach a point of
> zero acceleration and then start accelerating back toward Earth.
Uh. You're still missing something. After motor burnout, save for the
effect of air resistance, the rocket spends the entire flight
accelerating at 1g towards earth. You may want to consider a bit of a
refresher on newtonian physics :-)
> how do you estimate apogee by acceleration alone?
We assume the rocket is pointing upwards during ascent and integrate the
z-axis acceleration to compute change in speed. If we assume the rocket
starts at rest, then when the total change in speed gets us back to
zero, then we've stopped moving in that axis.
This is slightly complicated by gravity -- when the accelerometer
measures zero acceleration, we're actually accelerating towards the
ground at 1g, so we add 1g of acceleration to whatever the accelerometer
measures.
Don't expect TeleMega to work on the moon.
--
-keith
-----Original Message-----
From: altusmetrum-request <altusmetrum-request(a)lists.gag.com>
To: altusmetrum <altusmetrum(a)lists.gag.com>
Sent: Tue, Jun 25, 2019 5:04 pm
Subject: altusmetrum Digest, Vol 94, Issue 7
Send altusmetrum mailing list submissions to
altusmetrum(a)lists.gag.com
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.gag.com/mailman/listinfo/altusmetrum
or, via email, send a message with subject or body 'help' to
altusmetrum-request(a)lists.gag.com
You can reach the person managing the list at
altusmetrum-owner(a)lists.gag.com
When replying, please edit your Subject line so it is more specific
than "Re: Contents of altusmetrum digest..."
Today's Topics:
1. Re: BALLS Project (Keith Packard)
2. Re: BALLS Project (Clay and Carly Dunsworth)
3. Re: BALLS Project (Clay and Carly Dunsworth)
4. Re: BALLS Project (Clay and Carly Dunsworth)
----------------------------------------------------------------------
Message: 1
Date: Tue, 25 Jun 2019 12:13:39 -0700
From: "Keith Packard" <keithp(a)keithp.com>
To: Craig Klimczak <compuvet(a)aol.com>, altusmetrum(a)lists.gag.com
Subject: Re: [altusmetrum] BALLS Project
Message-ID: <8736jxo4v0.fsf(a)keithp.com>
Content-Type: text/plain; charset="utf-8"
Craig Klimczak <compuvet(a)aol.com> writes:
> Your're right. :-) I really don't understand what the
> accelerometers are reporting. I assumed that the accel would detect
> the de-acceleration as the rocket reached apogee, reach a point of
> zero acceleration and then start accelerating back toward Earth.
Uh. You're still missing something. After motor burnout, save for the
effect of air resistance, the rocket spends the entire flight
accelerating at 1g towards earth. You may want to consider a bit of a
refresher on newtonian physics :-)
> how do you estimate apogee by acceleration alone?
We assume the rocket is pointing upwards during ascent and integrate the
z-axis acceleration to compute change in speed. If we assume the rocket
starts at rest, then when the total change in speed gets us back to
zero, then we've stopped moving in that axis.
This is slightly complicated by gravity -- when the accelerometer
measures zero acceleration, we're actually accelerating towards the
ground at 1g, so we add 1g of acceleration to whatever the accelerometer
measures.
Don't expect TeleMega to work on the moon.
--
-keith
Keith:
> Uh, I think you're missing something here -- there's no change in any
> acceleration values across apogee; the rocket trajectory is ballistic
> precisely because the only large force acting on it is gravity, which is
> constant.
Your're right. :-) I really don't understand what the accelerometers are reporting. I assumed that the accel would detect the de-acceleration as the rocket reached apogee, reach a point of zero acceleration and then start accelerating back toward Earth. In retrospect, this is the vertical velocity vector. Since it is a vector and the rocket is pitching over the calculation requires some interpretation of the direction that the rocket is pointing. If the software is not integrating the direction of rocket, how do you estimate apogee by acceleration alone?
Craig
Our Maryland MDRA Team is building a high altitude project to fly at BALLS this year. The Avionics suite includes a TeleMega flight computer. The rocket is single stage dual deploy with a research motor. I'm reaching out to this forum for any advice on programming and using the TeleMega for rocket flights above the 100,000 foot mark.
Are there any special considerations for setting up the TeleMega for flights to over 100,000 feet?
Are there any considerations for rockets exceeding Mach 3?
What are the highest altitudes achieved with the TeleMega to date? I've flown this TeleMega to 35,000 feet with no problems. Is there an altitude where the performance of the TeleMega may be limited? Has anyone on this forum flown a TeleMege to 100,000 feet before. If so, how did it perform? Did you have any issues with tracking? Losing GPS lock? Apogee detection?
Thanks,Craig KlimczakTRA #13451
For a group project, I'm looking into replicatingfunctionality similar
to the Jolly Logic Chute Release, but with a pyro cutter instead of a
servo releasing a rubber band.
For mechanical reasons, the EasyMini would be mounted in the nose cone
and subjected to the ejection charge pressure. I'm not too concerned
about damaging the sensor, the sensor in the JLCR seems to handle the
same treatment quite well.
The flight is also planned to reach altitudes above the measurement
range of the sensor, so the flight would look something like this to the
EasyMini:
1) Liftoff
2) Altitude >100kft exceeded on ascent, sensor value clips
3) 1-3 pressure spikes around apogee, triggered by different altimeters
(multiple redundant charges, but ideally the EasyMini should only be
exposed to the first)
4) Altitude <100kft on descent, sensor value becomes valid again
5) Main altitude reached -> EasyMini releases chute.
In a couple of simplified tests in a vacuum chamber below 10mBar, the
EasyMini behaved as expected, but the pressure spikes were not simulated.
Do you expect issues from the pressures spikes regarding premature
detection of the main altitude, or is there any other thing that you can
think of the would preclude such "off-label" use of an EasyMini?
Thanks,
Reinhard
Is there a straightforward way to recover at least some data if a
readout results in a CRC error? I have an EasyMega here, that likely
experienced a loss of power around apogee (other devices on the same
battery were affected too) and I'd like to find out as much as possible
about this flight.
Thanks,
Reinhard
