[altusmetrum] TeleMetrum GPS questions

Bdale Garbee bdale at gag.com
Sat Oct 20 09:53:00 MDT 2012

Michael Stephens <engrstephens at gmail.com> writes:

> The GPS is locked out at Altitude < 18,000m or  Velocity < 515m/s.  It
> looks like my current sims show that I am going to get a hair to fast :)

The SkyTraq part actually only locks out when both conditions are
true... you can be "too high" or "too fast" as long as you aren't both
at the same time.

However, note that in addition to the COCOM restrictions, there is a
maximum acceleration limit of 4G above which the receiver loses lock.
So it's typically the case that for a rocket flight we have GPS lock on
the rail, lose it during boost, regain it early during the coast phase,
and retain it for the rest of the flight, except that the "Z" or
altitude value is laggy enough due to the filter design in the receiver
firmware that it can't be used to accurately determine apogee of a
rocket flight.

BTW, while our current SkyTraq part is great for rocket recovery, we'd
*like* to support GPS apogee determination too.  So we are both talking
to SkyTraq about firmware revisions, *and* considering a move to the
u-blox GPS receiver family, as possible changes in the future.

> Do we know what happens when it locks out? Does it come back? I'm assuming
> the unit fails gracefully when the GPS reciever fails.

It comes back just fine once you're within the COCOM limits again.

> i'll probably end up emailing them about this as well.

Keith and I both watch this list, we're just not always able to answer
immediately due to family and $dayjob commitments.

> I'm mainly interested in using the GPS as a starting point for the
> flight, the accel can carry it the rest of the way. I need the GPS
> during recovery to hopefully get its location because this thing is
> going to DRIFT. 

Sounds like it should work.  We've had a few folks fly our units with a
custom firmware build that just outputs telemetry including GPS position
once per second on high-altitude balloon flights.  Seemed to do what
they needed.

> The commandable pyro appears to only work in idle mode. I'd love to have
> this always active. I can probably recompile it hopefully to set this
> up.

Yes, of course, this is of course "just" an operational decision and not
a hardware limitation.  You're welcome to customize the firmware to meet
your needs, and we're generally happy to answer questions from folks
doing that.  FWIW, there's actually even a TARC team in Colorado Springs
working on a custom firmware load with very little guidance from us.
Neat stuff!  ;-)  

> It looks like what I am in need of is the TelePyro and or the
> TeleScience.

What do you want/need from these?

> Any ideas on timeframes for production/test unit and prices?

I've redesigned TeleScience to be more generally useful, and hope to
load the first v0.2 prototypes sometime in the next week or two.  I
just realized I haven't gotten around to updating the web page, though!
The new board moves to an STM32L151 ARM Cortex M3 system on chip that
we're going to be using for everything that isn't a CC1111 for a while.
It has support for 8 NTC thermistors in two banks of four that each use a
single through-hole resistor to match your chosen thermistors.  It has 3
AC/DC solid-state relays for doing things like pushing digital camera
buttons, 8 megabytes of on-board flash memory for data logging, and two
headers full of assignable analog and digital pins... pretty much
everything on the SOC is available to hook up to.

If the v0.2 board work, my plan is to hand-load early production units
until we have some idea what the demand is... so I could be offering
these boards by the end of the calendar year, perhaps?  

I have not worked out what companion board retail prices will be yet.

With respect to TelePyro, I've had prototype boards built for many
months, but firmware development stalled while we worked on another
product we hope to introduce early next year... so they've never
actually been completed or flown.  And in the meantime, working with the
prototype original TeleScience boards, we've grown to *really* dislike
various limitations in the AVR chip I used.  So... once the new
TeleScience is working, my plan is to redesign TelePyro to use the new
ARM-based SOC and try and get it on the market sometime in the first
half of 2013.

Hope that fills in a few gaps!  Feel free to ask if it raises other

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: <http://lists.gag.com/pipermail/altusmetrum/attachments/20121020/c49b042f/attachment.pgp>

More information about the altusmetrum mailing list