I haven’t been able to find a definitive wiring diagram for updating firmware for the TeleMini v3. Can I cut up a USB cable & connect the USB data+, data- and ground wires to the TeleMini v3 pins 1, 2 & 3?
Sorry to be a pain - If this thing was cheap I’d just try it. I’m trying my best not to let the smoke out though.
Thanks,
-Bryan
Hey everybody-
I set up a Debian sid machine and I’m trying to get everything building so that I can do some modifications for the TeleMini + external GPS project I’d like to do. Following the AltOS docs recommended build-dep/configure/make/install process didn’t work out of the box, so I’ve been crunching through the build errors a few hours each night over the last few days. Can someone please field some questions to help get me up & running?
First issue is with the Android SDK. Platform 23 looks to be the only one supported on sid, but configuration.ac checks for something >= 17 and also =10. Is the check for 10 just old code that can be removed? I can’t even find 10 to install, so it’d be great if it wasn’t required.
Second issue was with pdclib. I downloaded pdclib then built & installed it with jam as it says to on its wiki ( https://e43oss.atlassian.net/wiki/spaces/PDCLIB/pages/360465/Building <https://e43oss.atlassian.net/wiki/spaces/PDCLIB/pages/360465/Building> ). Does the AltOS makefile need the lines #all: pdclib/Makefile and git submodule update? Those give an error for me (because pdclib has a Jamfile & my pdclib directory isn't set up with git). It looks like the altos version on github doesn’t generate the same lines in its makefile ( https://github.com/ajtowns/altos <https://github.com/ajtowns/altos> ). I commented those lines out of the makefile & it looks like it’s going along fine without them, but are they required for some reason (aside from keeping pdclib updated)?
Third issue is with stlink in ao-stmload.c. stlink_common.h doesn’t appear to exist on my stlink install ( https://github.com/texane/stlink <https://github.com/texane/stlink> installed in in /usr/local/include). It’s just stlink.h. I changed the stlink_common.h reference in ao-stmload to stmlink.h. That lets things compile further, but I’m getting stlink_v1_open errors for having too few arguments now. Do I need to be using stlink from somewhere else?
Thanks!
-Bryan
Last weekend I launched a Madcow Arcas (2.6" thin wall fiberglass) with a
custom Nike Booster. I used a Aerotech DMS H550 on the first stage and a
H100 on the upper stage. The Nike Booster looked great and the separation
was clean (pyro-A, e-match), but the booster never fired. The igniter
(Pyro-B, e-match) maintained continuity (voltage) through drogue deploy
when the separation cut the wires to Pyro A and B. It doesn't appear I
exceeded the tilt limit on the flight and my goal was booster separation
1.5 sec after motor burnout and ignition 1 second after booster separation
(2.5 seconds after booster burn-out).
Can anyone tell me what I did wrong?
Attached its the eeprom data, csv, and a screen shot of the settings.
Might be useful to have a list of general settings for standard configs.
The only people who get this are list subscribers. There wasn't even any mention of the list in the manual. So helpful as this config you have provided is...
A it's after the event. Which I'll assume was expensive for the rocket owner.
B Should have been part of a standard config list disseminated with the manual. Preventing A
Norman McGeoch
TRA12957
Mob 0451 463 961
-------- Original message --------
From: altusmetrum-request(a)lists.gag.com
Date: 21/03/2018 5:00 AM (GMT+10:00)
To: altusmetrum(a)lists.gag.com
Subject: altusmetrum Digest, Vol 81, Issue 6
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: Fwd: Help with TeleMega setting for two stages (Keith Packard)
----------------------------------------------------------------------
Message: 1
Date: Mon, 19 Mar 2018 23:27:26 -0600
From: "Keith Packard" <keithp(a)keithp.com>
To: Gordon Bain <gbain.tx(a)gmail.com>, altusmetrum(a)lists.gag.com
Subject: Re: [altusmetrum] Fwd: Help with TeleMega setting for two
stages
Message-ID: <87muz3wc3l.fsf(a)keithp.com>
Content-Type: text/plain; charset="utf-8"
Gordon Bain <gbain.tx(a)gmail.com> writes:
> Can anyone tell me what I did wrong?
You set the 'flight state before' value to 'coast', which means that the
igniter will not fire unless the rocket has not yet reached 'coast'
state.
In this case, I think the settings you'd want are 'after motor 1', 'tilt
limit 20 degrees (for the sustainer ignition)', and 'delay after other
conditions 1 or 2.5 seconds'.
The 'state before' and 'state after' settings seem to be difficult for
many people to get their heads around; 'state before' means that the
rocket must have not yet reached the named state, 'state after' means
that the rocket has reached the named state. By setting 'state before
coast', you effectively require that the rocket still think that the
motor is burning, or that the rocket has not yet reached 100m (that's as
second condition on transitioning from boost to coast designed to avoid
false triggering from a motor chuff).
I have a plan to add some 'stock' configurations that will pre-configure
settings for some common cases like this.
I've also considered attempting to have some simulation mechanism so
that you can see what the settings you've made will do. However, you'd
want a wide range of possible simulations to check and make sure the
settings work in a range of possible flights; there are usually many
settings which work fine if the flight is nominal, but creating
appropriate settings that fail safely when the flight doesn't go as
planned means mapping out the whole failure tree.
It turns out multi-staged flights are hard; it looks like your flight at
least ended without damage, sorry you didn't get it to work correctly.
--
-keith
Altus Metrum announces TeleMetrum v2 back in stock and AltOS 1.8.5
TeleMetrum v2 back in stock
We're pleased to announce the current version of our classic flight
computer, TeleMetrum v2 is back in stock.
TeleMetrum v2 is a dual deploy flight computer with 2 pyro channels,
105g accelerometer, 100k' barometer, uBlox Max 7Q GPS and >30mW
telemetry system with APRS support. Read more about TeleMetrum v2
here:
http://altusmetrum.org/TeleMetrum
Announcing AltOS 1.8.5
AltOS 1.8.5 contains ground station software bug fixes for dealing
with TeleBT v4 and a few other minor updates.
* Bluetooth connections to TeleBT v4 weren't working on Linux and
Windows.
* The firmware updating process now verifies that the firmware matches
the target device.
* Fix flight computer power-on self-test beeping.
Read more about AltOS here:
http://altusmetrum.org/AltOS/
Thanks Keith!
So what is recorded is not necessarily exactly what is sent over Telemetry,
since that spike is not in the recording? Not a problem by itself, I just
want to understand what's the final source of truth - recording I assume.
Ed
On Mar 10, 2018 21:25, "Keith Packard" <keithp(a)keithp.com> wrote:
Edouard Lafargue <edouard(a)lafargue.name> writes:
> Hi!
>
> I noticed today that there was a significant discrepancy between the
> Android app max altitude that was recorded on a flight (719m), and the
same
> max altitude as saved on my Telemetrum (676m), and I was wondering if you
> have any idea where this might be coming from?
One might well have come from a baro pressure spike at apogee, so it's
always good to look at the recorded flight log to see what's up.
Any GPS data will always be marked as 'gps altitude' or 'gps height';
everything else is barometric because we can get a lot more data from
that, and small changes are more precise.
--
-keith
Hi!
I noticed today that there was a significant discrepancy between the
Android app max altitude that was recorded on a flight (719m), and the same
max altitude as saved on my Telemetrum (676m), and I was wondering if you
have any idea where this might be coming from?
Does the Android app interpolate the GPS altitude which is less precise,
or could there be another reason? I haven't had a chance to check the
source code yet to double check exactly what is being sent over the air...
Ed
Several folks have asked in the last couple days about the status of
TeleMetrum v2.0, so I figured I'd just let everyone know here that we
should have them back in stock around the end of March.
There are a few other items currently marked out of stock in the store,
all of which I expect to be back in stock within the next week or so.
Bdale
