altusmetrum September 2018

altusmetrum@lists.gag.com

12 participants
10 discussions

by Casey Barker

I see an error when running AltosUI.app 1.8.6 on Mac OS 10.13.6, running the stock Java 2017-001 from Apple. I also tried it on a second Mac OS computer, and it's consistent. I rolled back to 1.8.5, and the error goes away, so it's something between those two versions. Cannot launch Java application Uncaught exception in main method: java.lang.UnsupportedClassVersionError: com/sun/speech/freetts/VoiceManager : Unsupported major.minor version 51.0 Not sure if I should use the 1.8.5 UI with newer firmware, so I'll switch to a VM. Casey [image: Error.png]

4 years, 5 months

Issues with newer AltOS and TeleGPS applications connecting to TeleGPS with old TeleDongle

by Plugger Lockett

Hi Keith and Bdale, I believe I've identified an issue with the AltOS and TeleGPS applications when using an original TeleDongle for telemetry. The old TeleDongle assumption is just that but I'm assuming if this was a bug for all TeleDongles it would have been found before now. I "discovered" this issue when I attempted to use AltosDroid v1.8.5 in the field with my TeleGPS 1.0 and I couldn't get telemetry to work at all. So I attempted some bench testing over the weekend and I believe I've identified a bug in the newer software stacks. First off, here's my TeleDongle details. I started the process by upgrading my TeleGPS firmware. Not that it was needed or necessary but I prefer to run up to date software if at all possible so I took the opportunity to update both my TeleGPS and EasyMega to firmware version 1.8.5. Both updates were successful. So after I attempted to test the connection to the TeleGPS with a Windows 10 1803 build laptop running AltOS 1.8.5 and TeleGPS software v1.8.5. Below are the results of those tests. Strangely it appears that both applications are receiving some data from the TeleGPS radio, but it's not being interpreted/displaying correctly. AltOS v1.8.5 output TeleGPS Software v1.8.5 output So I reverted back to another laptop (also Windows 10, build 1803) that is my "known good config" TeleGPS Telemetry host. As soon as I opened the TeleGPS app with my TeleDongle plugged in I was receiving successful telemetry data automatically within ~10 seconds, as expected. I fired up the AltOS app on the same host and that also connected fine. So I checked my software version on the working host, both the TeleGPS and AltOS apps were running version 1.7. So I then went back to the original laptop and downgraded both the TeleGPS and AltOS applications from v1.8.5 to v1.7 and ran the tests again. Both worked successfully (see below) AltOS v1.7 output TeleGPS Software v1.7 output I was running these tests indoors so I'm unconcerned with the lack of GPS lock. I then uninstalled v1.7 of each application and reinstalled v1.8.5 and retested and confirmed v1.8.5 didn't work. I then rolled back to v1.7 as I need telemetry working, tested, and everything worked fine. But this led me to a few questions. 1) Assuming v1.8.6 is affected by this bug as well (I'll test that in the next few days) then can you investigate this issue? 2) I've got an EasyMega as mentioned earlier and am planning to use it in a 2 stage stack in April. I will be upgrading the firmware to v1.8.6 as recommended. - Do I need to be running the latest software to properly configure staging and get correct CSV output post flight? Or will AltOS v1.7 do this correctly with a EasyMega v1.8.6 FC? 3) AltosDroid - Ideally I'd like to use my phone (Pixel XL) as my ground station in conjunction with my TeleDongle. I've had this work in the past but my AltosDroid software automatically updates and is currently running v1.8.5 as well. Is there somewhere I can download the AltosDroid v1.7 apk in the interim until this bug is resolved? If you have any questions please let me know. Regards, Andrew Hamilton

4 years, 5 months

Frequency response of extra pyro inputs on TeleMega?

by Stewart Campbell

Hi, I am using the extra four inputs on the TeleMega to provide logging of my servo PWM commands on my Vertical Trajectory System. I was wondering what filtering you have on those inputs and what the logging rate is please? I see there is no capacitor for filtering the input, just a voltage divider, so I assume you are using an IIR filter (or Kalman?) of some sort since the logging trace is quite clean :-) . I am trying to figure out if I should be able to see signals in the region of 2.5Hz (give or take) or perhaps a little faster, or be able to estimate any attenuation or phase shift I might be seeing. Any info would be greatly appreciated. If it is a bit sluggish, is it possible to crank it up a bit faster maybe? Also, what is the logging rate and frequency response on things like XYZ roll, acceleration, etc please Sorry for the tricky questions :-) Thanks Stewart Campbell

4 years, 5 months

Stock availability

by Plugger Lockett

Hi Keith and Bdale, Any word on when stock will be refreshed in the Garbee and Garbee web store? The EasyMega, TeleMega, EasyMini, TeleDongle, and the MicroPeak USB v2 are all listed as out of stock. I'm in the market for 3 of those products and ideally I'd like to purchase them in the next month or two. Any updates would be appreciated. Cheers, Andrew Hamilton

4 years, 5 months

TeleMega 3.0 Firmware

by Casey Barker

Does the TeleMega 3.0 hardware use 2.0 firmware? That's all that's in the altos package, but I flashed it and now I'm getting bad-sounding beeps... Casey

4 years, 6 months

Telemega

by Tim Navickas

I had a flight at Airfest using a Telemega that I have some questions on. I launched a rocket with a M3100 and it went to pieces in a few seconds!!! My questions are what can I make of the data and how do I tell if the Telemega is OK. The data I question is the maximum height. I believe the GPS height. Is the difference do to the rocket going disintegrating and the pressure around the avionics bay being weird? I recalibrated the unit and it passed but how do you know if the unit is still good? The unit did transmit its coordinates and that part is OK Thanks, Tim

4 years, 6 months

EasyMega apogee config recommendations for flights over 100k'

by Plugger Lockett

Hi Everyone, To provide a bit of background, I'm attempting to assist Mike Passaretti with getting an electronics apogee deployment configuration nailed down for his planned flight at Balls this year. His initial plan was to use two Raven 3s to provide all the required deployment events in his flight. Unfortunately his Raven 3s aren't high alt firmware models and it seems there isn't even a high alt firmware available for the Raven 3 boards. Given this we're running into some pretty severe board configuration limitations and about the only way we can get a apogee deployment configuration to work given these limitations is to program around the baro sensor cutting out (apparently this occurs at 104k' MSL) and then add a delay to the event calculated by taking the simulation time it takes to get to 104k', subtract that from the simulation time to apogee, and configure the delay time value to be equal to that value. As you can imagine this is not an entirely ideal approach. Given this I've offered Mike my EasyMega with the latest firmware to use. But I wanted to ask the list what is the recommended method for getting reasonably accurate apogee deployment events to work when you're above the effective range of the baro sensors we use on our various FCs. My expectation is that at worst I can configure the pyro event as a simple timer by enabling the following configurations. Pyro Channel A *Height above pad greater than (m)* enabled and configured for *10,000* meters to ensure Mike's well above ground for the event to occur. *Time Since launch less than (s)* enabled and configured for *85* seconds. *Time Since launch greater than (s)* enabled and configured for *84 * seconds. Would that configuration work as a "pure timer" apogee deployment event envisioned for 84 seconds after liftoff? Is there another way to configure apogee deployment events above 100k' on the EasyMega that would be a smarter or more advantageous way of accomplishing this task instead of a simple timer configuration? Any advice in this area would be much appreciated folks. Kind Regards, Andrew Hamilton

4 years, 6 months

Terminal Blocks

by Jeff Jones

Can you direct me to the EXACT 6 terminal block you use on the Telemetrum. I have tried a few different ones from Digikey that are close but nothing is an exact fit, thanks.

4 years, 6 months

Reprogramming TeleMetrum apogee channel

by Cyrus Boushehri

Hello Altus Metrum, I have a TeleMetrum (v2.0b) dual deployment controller that I use in a rocket of mine to deploy the main chute. I am hoping to add a booster stage that would disconnect after burnout, via a controlled charge. I know there are flight computers that support this kind of functionality, but I was wondering if I might be able to reprogram the apogee channel (currently unused in this rocket) to a purely timed firing. Unlike airstart controllers, I don't need it do be dependent on angle of attack, as it only governs the disconnection mechanism, so I don't think it should be too difficult, but I have no familiarity with the TeleMetrum hardware. If anyone has advice about this idea, I would appreciate any input. Thank you, Cyrus.

4 years, 6 months

One more newbie TeleMega question

by Gary Lech

I've looked high and low and kinda know the answer but thought I'd ask anyway. Can the TeleMega be configured using the AltosDroid version? It's easy enough to make changes using the AltosUI Windows version but using a smartphone for changing things like the callsign would be a nice feature. Or am I completely missing it somewhere like in a case of refrigerator blindness which my wife likes to tell me? I'm ready to fly 'em. Thanks for all the help, Gary

4 years, 6 months

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

altusmetrum September 2018