just installed the new version on a brand new Macbook with the M1 chip. It appears to run and download data, but I have no way (or don’t know how) to say where it will be stored. The program made an Altus Metrum folder in my user account, not even in the Documents folder, which is not where I want the stuff to go. After I moved that folder and when I try to export or open and look at data I can’t navigate to where I put the files. Thoughts or suggestions?
I haven’t tried monitoring a flight yet, but is there a separate TeleGPS app? If there is, I can’t find it. I copied the one I had from the old computer and running it, the program says “No AltOS library in “/Applications/TeleGPS.app/Contents/Resources/Java”.” But then it starts but doesn’t look to do anything. On the hardware side, will I need to update the TeleGPS transmitters? It says it is running version 1.9.7.
thanks,
Charlie
I just installed the new version on a brand new Macbook with the M1 chip. It appears to run and download data, but I have no way (or don’t know how) to say where it will be stored. The program made an Altus Metrum folder in my user account, not even in the Documents folder, which is not where I want the stuff to go. After I moved that folder and when I try to export or open and look at data I can’t navigate to where I put the files. Thoughts or suggestions?
I haven’t tried monitoring a flight yet, but is there a separate TeleGPS app? If there is, I can’t find it. I copied the one I had from the old computer and running it, the program says “No AltOS library in “/Applications/TeleGPS.app/Contents/Resources/Java”.” But then it starts but doesn’t look to do anything. On the hardware side, will I need to update the TeleGPS transmitters? It says it is running version 1.9.7.
thanks,
Charlie
Plugger Lockett <plugger.lockett(a)gmail.com> writes:
> Sorry Keith and Bdale. I just received this message and I can't help but
> think gmail isn't the root cause of this problem. I routinely go into my
> spam/junk folder and mark Altusmetrum mailing list messages as "not
> spam"
Yep, our latest 1.9.11 announce email appears to have generated bounce
messages for every recipient using gmail.
Chasing the error messages I'm seeing, it appears that gmail has gotten
relatively vicious about accepting email from other sites that aren't
implementing a pile of email anti-spam measures they've decided are
important. I suspect they think this is a great idea to protect gmail
users from random spam sources, but it sure feels from where I sit like
at best a "you're guilty until proven innocent" thing.
I've already made some additions to my config, but clearly my gag.com
email relay is not yet satisfying Google. I'll work on this as I have
time, but in the meantime, I guess all I can say is "sorry" to anyone
subscribed to our list who uses gmail.
Bdale
Altus Metrum announces AltOS 1.9.11
Announcing AltOS 1.9.11
Altos 1.9.11 is another bug-fix release.
AltOS Changes:
* Make Apogee Delay work again.
* Allow TX power to be limited to 10mW for compliance with
some uses under UK regulations.
* Fix numerous minor issues with 16- vs 32- bit time values.
AltosUI Changes:
* Support M1-based Macs, follow AdoptOpenJDK to Adoptium
AltosDroid Changes:
* Handle Bluetooth permissions reliably.
* Fix some screen rotation bugs.
Read more about AltOS here:
https://altusmetrum.org/AltOS/
"David W. Schultz" <david.schultz(a)earthlink.net> writes:
> There are some things in that data that don't make sense to me.
>
> At 9.4s there are spikes in the pressure and acceleration, similar to
> what you see in ejection events.
>
> At 9.47s the state machine switches to the flight_drogue state. (This
> should be the triggering event for the drogue output.) You can also see
> the change in sample rate (100SPS to 10SPS) just after that. The
> velocity at that time is ~240m/s.
Note that flight state changes are recorded in data records that occur
at a lower rate than the acceleration records, so the spikes in pressure
and acceleration are most probably the drogue charge firing.
> On the following sample (the last at 100SPS) at 9.48s, the velocity
> drops to ~90ms. There is nothing in the acceleration or pressure data
> that would do that.
The ground software plotting the data switches from accelerometer
integration to altitude derivatives to compute vertical speed after apogee.
> The code to change from the coast state to drogue state requires that
> velocity by negative. Nothing else in ao_flight.c changes to that state.
> (That is a global variable so could be changed anywhere.) The recorded
> data doesn't come close to a negative velocity at that time.
There is no recording of vertical speed, the ground software computes it
by integrating acceleration (during ascent) or differentiating altitude
(during descent).
In flight, the software uses a Kalman filter that fuses both barometric
and acceleration data to model height, speed and acceleration. Because
the barometric data was so erroneous, that model was far from correct,
and mis-estimated vertical speed badly.
> Questions:
>
> 1) Why did the state machine change to the drogue state?
The Kalman estimate of speed went negative.
> 2) Why is there a discontinuity in velocity at 9.48s?
The ground software changes its method of computing vertical speed after
apogee.
> 3) What happened at 9.4s?
The drogue charge fired at 9.4s, but that wasn't recorded until later.
I need to fix up the test code which can take the recorded data and run
the Kalman filter on my laptop; that was broken when we made a few
changes to how time is stored recently. With that, we can verify that
the Kalman filter is working as expected.
Any flight software is full of assumptions and compromises; this
firmware makes assumptions about the quality of the barometric data, and
in this case, those assumptions were not correct. In previous firmware
versions, we ignored barometric data above mach 1, but that caused
problems when the accelerometer had an offset error and the flight was
above mach 1 for a sustained period of time.
As the accelerometer almost always has a small offset error because of
it's wide range, we decided to re-introduce barometric data above mach
1, but assign a larger error margin so that more noise didn't end up in
the model. However, it still assumes gaussian error, centered around the
true value (as is required for a Kalman model to function).
It's the large amount of offset error in the barometric data from this
flight which caused the fault here; that offset slowly slewed the model
to an inaccurate vertical speed estimate. Mix that into the deceleration
measured by the accelerometer and you get an early apogee estimate.
--
-keith
Hey everybody. I’m did a record attempt flight this morning and it looks like I got an ejection firing while the rocket was still going over 800ft/s. The pressure graph looks really strange.
This flight was planned as a single deploy (redundant apogee set, but only 1 charge). I’ve flown a similar rocket with the same static port/vent config, the same TeleMetrum and nearly the same flight profile before. Does anyone have any ideas as to what could be going on?
Here are some screenshots of the flight data: https://imgur.com/a/SLBizL1 <https://imgur.com/a/SLBizL1>
I attached a zip of the flight data eeprom file (not sure if the list will allow that though).
Thanks!
Bryan
I pulled the TeleMetrum from the avbay & don’t see any obvious obstructions or problems (well, obvious to me). The only “hmm” is if you zoom into the pressure sensor, you can see two little things in the right hole. I’m not sure if those are supposed to be there.
Here’s a photo showing the pressure sensor. https://imgur.com/a/GEgHYXd
Thanks,
Bryan
> On May 28, 2022, at 10:31 AM, Bryan Duke <bryan(a)thedukes.org> wrote:
>
> Hey everybody. I’m did a record attempt flight this morning and it looks like I got an ejection firing while the rocket was still going over 800ft/s. The pressure graph looks really strange.
>
> This flight was planned as a single deploy (redundant apogee set, but only 1 charge). I’ve flown a similar rocket with the same static port/vent config, the same TeleMetrum and nearly the same flight profile before. Does anyone have any ideas as to what could be going on?
>
> Here are some screenshots of the flight data: https://imgur.com/a/SLBizL1
>
> I attached a zip of the flight data eeprom file (not sure if the list will allow that though).
>
> Thanks!
> Bryan
> _______________________________________________
> altusmetrum mailing list -- altusmetrum(a)lists.gag.com
> To unsubscribe send an email to altusmetrum-leave(a)lists.gag.com
Hi,
I have been updating everything to the latest 1.9.10 firmware and when I tried to open the software on my Android phone it crashes immediately. Has anyone else noticed this and figured out what is wrong?
