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:
: 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.
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
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
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
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
- 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.
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 :-)
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.
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
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
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 *
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.
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.
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,