Michael Stephens <[email protected]> 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 questions. Bdale
pgpzHUS0DWQCm.pgp
Description: PGP signature
_______________________________________________ altusmetrum mailing list [email protected] http://lists.gag.com/mailman/listinfo/altusmetrum
