Keith and I both hope to be able to attend "Thunda Down Under"[1] in
2015, and I've sent the organizers email requesting information on what
it takes to be treated as an on-site vendor.
Of course, it's always more fun to be at a launch when you have something
interesting to fly! Thus, while Keith and I might each show up with a
modest "travel rocket" of some sort... I've started pondering possible
larger "Altus Metrum" group projects. Since transporting a large
airframe to Australia would be a hassle, I wonder if a group project to
build an airframe in-country makes more sense? To that end, I'd be
pleased to know if any of our friends and customers in Australia want to
sign up to help with such a project?
My thoughts would be to engage in some group-think about project scope
and goals, then hope friends in-country would take on the sourcing and
preparation of suitable airframe materials. Depending on who wants to
participate and how tasks get taken up, we might plan to arrive a bit
early to help with any final assembly or other preparations,
installation of suitably fresh Altus Metrum electronics, etc.
So, to all our Aussie friends... does this sound like fun? If so,
please chime in with a reply. I don't expect the email associated with
such a project to be too heavy a load for this list to carry, but we can
always spawn a dedicated lists.gag.com list if I'm wrong.
Regards,
Bdale
[1] http://thunda.com.au/
Not working here. I tried the D72A and paired a Mobilinkd TNC1 to a Nexus 7 with a plain H/T.
Packets come across but nothing is decoded. With the Mobilinkd, I made certain it was decoding APRS packets properly off the air on 144.390 and then used a 70cm Beeline GPS. All worked fine there including packets transmitted from the D72A and off-frequency D7's.
I could "hear" the data packet on the TeleGPS coming in but no decode. Does a separate
APRS packet get sent in between the GFSK data bursts or is it mixed in with the data bursts?
If it's separate I do not hear anything that resembles the APRS sound. If it's "mixed in" with the
Altus metrum format, it sorta sounds like an APRS packet but is not decoded.
Nonetheless, if my settings are appropriate, I believe the TeleGPS I have is not behaving up
to spec if it's supposed to be able to send an APRS packet. I'll wait till I hear from Keith or
B'dale and see what they say about my settings.
I've used three rigs to attempt to decode packets (although I didn't expect much from the off
frequency D7) two of which work fine with 2 meter and 70cm off-air packets. I'm stumped.
Kurt KC9LDH
________________________________
From: Douglas Bertelsen <douglas.bertelsen(a)gmail.com>
To: Kurt <ksaves2(a)sbcglobal.net>
Sent: Saturday, January 31, 2015 9:26 AM
Subject: Re: [altusmetrum] Contact Form
Those settings gave me good packets. All else failing, can you record the audio from the radio during transmissions and post it if those settings don't work? I can compare it to what I hear and maybe give some insight.
Doug
I flew my TeleMega, serial #1639 with 1.4.1 at Balls in a 2 stager.
Ran into a few problems, as follows:
1. Unable to connect in to TeleDongle in idle mode. I had previously
found that I couldn't get a connection with the TeleMega in channels
7-9, so I was using channel 3 for this flight. I was unable to get a
connection in idle mode in Channel 3. I haven't explored other channel
or tried to re-create this problem.
2. RFI issue with Beelines. The rocket had 4 Beeline trackers in it as follows:
- 1x 100mw 70cm GPS aprox 30" above the TeleMega on 434.350
- 1x 70cm beacon aprox 6" below the TeleMega on 438.850
- 1x 16mw 70cm GPS aprox 48" below the TeleMega on 434.350
- 1x 70cm beacon aprox 48" below the TeleMega on 438.350.
With any combination of the beacons turned on, attempting to startup
the TeleMega in pad mode would result in battery voltage beeps, pad
mode beeps followed by silence, on both the radio (I was listening in
to 434.850 on my FT1DR) and buzzer (ie, no continuity beeps). After
spending an afternoon troubleshooting this, it was determined that
turning on any combination of the Beelines prior to startup would
cause this, but turning them on after the TeleMega was transmitting
didn't result in any adverse affects.
In investigating the manual post-flight, I did note the point about
twisting wires, which I did not do on this flight as I hadn't seen it
previously. I'm not certain that that would have fixed the issue or
not. It would be really really great if there was a separate manual
for each product. It's very easy to miss things when you are
intentionally skipping a significant portion of the manual since it
doesn't relate to the product you are interested in. Additionally,
this is the only time I've seen a suggestion in a manual to twist
wires. This comes in a section of the manual, that in most other
rocket electronics manuals, is reserved for things like "how to attach
wires to screw terminals" and "how to not have battery issues", which
experienced fliers have a tendency to already know and skim.
3. Accel calibration with temp. After spending an afternoon at the pad
troubleshooting the above issue, the rocket sat overnight and was
powered up within 30 minutes of sunrise. I was unable to get the
TeleMega into pad mode until it had been in the sun for 10 minutes, at
which point, it went into pad mode and read a Z accel of -5.1m/s/s. We
left the rocket in the sun for the next 45 minutes and in that time,
the Z accel when it was being held vertically had migrated from -5.1
to -3.3 to -2.2 and was continuing its upward trend. The accelerometer
was previously calibrated at room temp 2 weeks prior to the launch.
4. Angle lockout for staging-not so much a bug as it's probably
exactly what it's designed to do, but I had the telemega setup to do
staging and also staging inhibit on a backup timer. The TeleMega was
to stage if conditions were after burnout, >4 seconds into flight, <25
degrees and >400m/s. I had an additional circuit acting to open the
igniter circuit on a timer I was using for backup. This was to occur
if the angle exceeded 25 degrees at any point. Shortly after the
breakup, the inhibit circuit fired as anticipated. What I didn't
expect was for the fire circuit to fire as the rocket rolled back
within 25 degrees of vertical 2 seconds later. Fortunately the igniter
had already ripped out of the motor, so no harm was done, but this
could have been interesting had it not.
Anyway, hopefully this helps alleviate frustration for at least
someone. I understand the issues now and they're more annoyances that
I can live with than anything. As I hadn't seen them documented
previously, I figured I'd put them out there. Let me know if anyone
has further questions or needs more elaboration.
Thanks,
-Andrew
wexpeter <wexpeter(a)gmail.com> writes:
> Have used Telemetrums over the last few years - very happy with the
> product.
Thanks for the kind words, Peter!
> A university rocketry club my son is in is considering a carbon fiber
> HPR. They are considering 900MHz — I am trying to convince them to get
> the license and use the Telemetrum. Question is what others have used
> for an antenna. My assumption is it has to be external if carbon
> airframe. Single external wire? Other suggestion? Clearly some gain on
> the ground will be important.They are thinking possible max altitude
> of 50K. Any suggestion greatly appreciated.
>
> Peter Wexler
> WA2COM
> LUNAR/NAR/Tripoli
I'm going to CC our mailing list on this reply in case others want to
chime in, because the whole issue of what to do for antennas on
predominantly CF airframes is a fairly frequent question to us.
My personal preference is to include a non-CF section in the airframe.
For example, make the walls of the electronics bay out of glass, or use
a glass nosecone, into which the various antennas can be places. The
reason this is a big win is that you're actually worrying about *2*
antennas, not one .. the GPS patch needs a clean look at the sky or you
won't get a GPS lock, and the signal from the UHF downlink antenna
obviously needs to be able to propagate out from the airframe.
In our original TeleMetrum design, we were forced for several reasons to
use a GPS patch antenna with an integrated preamp that had a short piece
of small diameter coax wrapped around the board plugged into a U.FL
connector on the board. With those boards, remoting the GPS antenna was
at least theoretically pretty easy. You could disconnect that cable,
put in a U.FL extension or U.FL to SMA adapter cable, and put the
amplified GPS antenna of your choice somewhere else in the airframe.
But in practice, this often turned out to be a real pain. The U.FL
connectors aren't really designed for many insert/remove cycles (think
10'ish), adapters are expensive / heavy, as are standalone amplified GPS
antennas. Thus, not many people actually did this...
In our current products, all of the GPS antennas are passive patches
soldered directly to the board. The front-end on the u-blox MAX-7Q GPS
receivers we're using now is sensitive enough that this works out pretty
well, and the inclusion of a SAW filter plus *very* carefully designed
layout keeps the UHF transmitter from swamping the GPS receiver input.
The downside is that remoting the GPS antenna has gotten a lot harder
with current products like TeleMetrum v2.0 and TeleMega.
We no longer offer a purchase-time option for putting an SMA connector
on the board instead of a wire whip antenna, but the footprint is still
there, and I still sell the right SMA connectors. We've observed that
downlink signals from a simple wire soldered to the board are often much
stronger than when you put a "commercial" antenna on an SMA .. this
is partly because most "rubber ducks" are actually really lousy antennas
(including the ones we used to sell, sadly!), and partly because the
design of the PCB is such that a simple 1/4 wave whip on the end of the
board gets an exceptionally good signal "launch". So, if you really want
to remotely mount a UHF downlink antenna, it's not hard to do, but we
don't usually recommend it. For a good example of when/why you might
want to do it, have a look at my write-up for YikStik3, particularly the
description of my "fintenna" and the associated photos taken during the
build:
http://gag.com/rockets/airframes/YikStik3/http://gallery.gag.com/rockets/YikStik3/Build/cimg1949.jpg
The performance of the fin-can downlink on that airframe, once I
re-tuned everything with the Pro75 6xl case in place, was
*outstanding*. I really wish I still had that airframe... on its maiden
flight it set new personal speed and altitude records for me. But, like
so many others, it was lost in the fire.
Bottom line? It's *possible* to remote antennas from our products, but
it's not something to be taken lightly. By far, the better approach is
to include an RF-translucent section somewhere in the airframe to house
the board(s).
There are so many different "900 Mhz" products out there that I can't
speak to them without more details, but you're unlikely to find anything
operating on that band that gives a more satisfying result than using
one or more of our products... ;-)
I hope this helps!
Bdale
Why not just add another condition?
(Angle < X) and (Time > Y) and (Altitude > Z)
Figure out where you should be when you stage, subtract a bit to allow for some performance margin, then set accordingly. If you're tumbling you likely won't achieve the altitude at which you want the staging to happen.
-Kevin
From: altusmetrum [mailto:altusmetrum-bounces@lists.gag.com] On Behalf Of Casey Barker
Sent: Monday, March 02, 2015 8:27 PM
To: Altus Metrum
Subject: [altusmetrum] Stage Ignition Logic on TeleMega
Hi folks,
The AeroPac 100K team flew TeleMegas last year on some, er, "less than successful" two-stage flights. The failures were related to other issues, but they did enlighten us on a few corner cases in TeleMega programming, particularly around second stage ignition. I've been thinking about possible improvements, and I'd like to get your thoughts.
I wasn't able help the team much last year, so my understanding of the flights and programming is third-hand. However, I'm told that we conditioned the second stage ignition on ((Angle < X degrees) AND (Time > Y seconds)). Programmers may already see an issue.
Our first flight suffered a fin de-lamination during the boost that sent the stack into a tumbling ascent. At some point during that tumble (and after the requisite Y seconds), the sustainer lit. We figured that, while tumbling, the sustainer must've briefly pointed upward < X degrees and satisfied the ignition condition. (I believe on the second flight, we added a "Time < Y+1 seconds" to try and prevent that condition. Unfortunately, that flight failed for entirely different reasons.) Still, if the condition is satisfiable after tumbling, it seems like we'd be better off with some sort of lockout or latch, perhaps a "largest orientation angle seen since launch" condition.
Meanwhile, I had some ideas about using clever flight electronics to achieve actual performance improvements. When going for altitude, the second stage ignition time is a tradeoff: If you wait too long, the sustainer arcs over, and you waste energy by going sideways. If you don't wait long enough, you ignite at high speed, resulting in higher sustainer velocity for the duration of the burn, and thus higher drag and wasted energy. (Not to mention the higher chance of fin removal.) So I wondered if we could design an "optimal coast" strategy, such that we wait until the sustainer tips over at least, for example, 5 degrees before igniting, but don't wait longer than Z seconds (in the unlikely event that the sustainer back-slides). This is getting algorithmic, so I'm better off expressing it in pseudo-code:
config EarliestIgnitionTime = 15 seconds // Depends on booster motor
config LatestIgnitionTime = 25 seconds // Depends on booster motor and sustainer inertia
config AbortLockoutAngle = 20 degrees // Depends on TRA regs and/or how far we want to recover
config OptimalCoastMaxAngle = 5 degrees // Do you feel lucky? Could sim to determine optimality.
variable SustainerAbortMode = False // Persistent state, starts out false
loop {
if (currentAngle > AbortLockoutAngle)
set SustainerAbortMode = True // One-way latch, persists from now on, sustainer aborted.
if (SustainerAbortMode == True)
loop_again or just exit // Once we abort, we will never, ever light the motor.
if (currentTime < EarliestIgnitionTime)
loop_again // Booster still burning, haven't separated yet.
if (currentTime < LatestIgnitionTime) AND (currentAngle < OptimalCoastMaxAngle)
loop_again // Still coasting nearly straight up, so keep going for altitude.
// Either the angle is no longer optimal, or we
// reached the latest time we wanted to wait, so...
light_the_motor()
}
I doubt that's compatible with the run loop in the firmware, but it expresses the desired conditions.
I can even imagine a complex condition using simulation results to develop and program a time (or even velocity) vs. orientation "ignition curve." Hoo-boy. Maybe I've had too long of an off-season to noodle on such things. :)
Any thoughts on these ideas? I'm hoping to finally have time to tinker with rockets again soon, so if I were to dig into firmware, any suggestions on how to implement and unit test this?
Casey
Hi folks,
The AeroPac 100K team flew TeleMegas last year on some, er, "less than
successful" two-stage flights. The failures were related to other issues,
but they did enlighten us on a few corner cases in TeleMega programming,
particularly around second stage ignition. I've been thinking about
possible improvements, and I'd like to get your thoughts.
I wasn't able help the team much last year, so my understanding of the
flights and programming is third-hand. However, I'm told that we
conditioned the second stage ignition on ((Angle < X degrees) AND (Time > Y
seconds)). Programmers may already see an issue.
Our first flight suffered a fin de-lamination during the boost that sent
the stack into a tumbling ascent. At some point during that tumble (and
after the requisite Y seconds), the sustainer lit. We figured that, while
tumbling, the sustainer must've briefly pointed upward < X degrees and
satisfied the ignition condition. (I believe on the second flight, we added
a "Time < Y+1 seconds" to try and prevent that condition. Unfortunately,
that flight failed for entirely different reasons.) Still, if the condition
is satisfiable after tumbling, it seems like we'd be better off with some
sort of lockout or latch, perhaps a "largest orientation angle seen since
launch" condition.
Meanwhile, I had some ideas about using clever flight electronics to
achieve actual performance improvements. When going for altitude, the
second stage ignition time is a tradeoff: If you wait too long, the
sustainer arcs over, and you waste energy by going sideways. If you don't
wait long enough, you ignite at high speed, resulting in higher sustainer
velocity for the duration of the burn, and thus higher drag and wasted
energy. (Not to mention the higher chance of fin removal.) So I wondered if
we could design an "optimal coast" strategy, such that we wait until the
sustainer tips over at least, for example, 5 degrees before igniting, but
don't wait longer than Z seconds (in the unlikely event that the sustainer
back-slides). This is getting algorithmic, so I'm better off expressing it
in pseudo-code:
config EarliestIgnitionTime = 15 seconds // Depends on booster motor
config LatestIgnitionTime = 25 seconds // Depends on booster motor and
sustainer inertia
config AbortLockoutAngle = 20 degrees // Depends on TRA regs and/or how
far we want to recover
config OptimalCoastMaxAngle = 5 degrees // Do you feel lucky? Could sim to
determine optimality.
variable SustainerAbortMode = False // Persistent state, starts out false
loop {
if (currentAngle > AbortLockoutAngle)
set SustainerAbortMode = True // One-way latch, persists from now on,
sustainer aborted.
if (SustainerAbortMode == True)
loop_again or just exit // Once we abort, we will never, ever light
the motor.
if (currentTime < EarliestIgnitionTime)
loop_again // Booster still burning, haven't separated yet.
if (currentTime < LatestIgnitionTime) AND (currentAngle <
OptimalCoastMaxAngle)
loop_again // Still coasting nearly straight up, so keep going for
altitude.
// Either the angle is no longer optimal, or we
// reached the latest time we wanted to wait, so...
light_the_motor()
}
I doubt that's compatible with the run loop in the firmware, but it
expresses the desired conditions.
I can even imagine a complex condition using simulation results to develop
and program a time (or even velocity) vs. orientation "ignition curve."
Hoo-boy. Maybe I've had too long of an off-season to noodle on such things.
:)
Any thoughts on these ideas? I'm hoping to finally have time to tinker with
rockets again soon, so if I were to dig into firmware, any suggestions on
how to implement and unit test this?
Casey
