Re: [psas-software] [PSAS] some data analysis from the 2005 launch
On Tue, Nov 20, 2007 at 09:00:07AM -0800, Jamey Sharp wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 11/20/07, mark gross <[EMAIL PROTECTED]> wrote: > > On Thu, Nov 15, 2007 at 10:11:02AM -0800, Jamey Sharp wrote: > > > 4-byte big-endian "ID" > > > 4-byte big-endian timestamp > > > 8 bytes of data > > > > OK, so now looking at the Rocketview_20050820.log using hexedit which lists > > out the data in 18 byte chunks. > > You meant 16, surely. > yeah 16. > > I'm not seeing the above record format ... > > `hexdump -v 20050820.log` shows me one sensible-looking message per > line, though AFAICT it treats the input as native-endian and can't be > forced to big-endian. Help me interprit the following: 1490 00 00 73 01 00 00 1E B4 34 00 04 A5 07 31 07 75 ..s.41.u 14A0 00 00 0B 50 00 00 00 00 00 00 00 30 00 00 00 00 ...P...0 14B0 00 00 09 41 00 00 1E B7 30 00 04 A5 07 31 07 75 ...A01.u 14C0 00 00 2B 90 00 00 00 00 00 00 00 30 00 00 00 00 ..+0 14D0 00 00 2B 81 00 00 1E BB 01 00 04 A5 07 31 07 75 ..+..1.u 14E0 00 00 2B B0 00 00 00 00 00 00 00 00 00 00 00 00 ..+. 14F0 00 00 2B A1 00 00 1E BF 00 00 04 A5 07 31 07 75 ..+..1.u id id ts ts ts ts dd dd dd dd dd dd dd dd Whats with the wacky ordering of the id bytes? I was expecting that I could use the can id's to infer time stamp. What are there lines with no time stamps? 00020160 00 00 01 A8 00 00 00 00 FF FF 7F E1 07 00 00 00 00020170 00 00 01 E4 00 00 00 00 00 01 59 74 20 92 09 0A ..Yt ... 00020180 FF FF F0 28 00 00 00 00 76 07 0D 2D 00 02 1F 85 ...(v..- 00020190 FF FF F8 04 00 00 00 00 00 02 00 04 E0 FB 3F BF ..?. 000201A0 FF FF F8 A1 00 00 00 00 07 02 00 04 E0 FB 3F BF ..?. 000201B0 FF FF F8 27 00 00 00 00 14 08 07 D5 13 34 06 BF ...'.4.. 000201C0 FF FF F8 48 00 00 00 00 04 8E CD 4E F3 73 07 53 ...H...N.s.S 000201D0 FF FF F8 64 00 00 00 00 00 03 44 01 F3 73 07 53 ...d..D..s.S 000201E0 00 00 53 08 00 02 3D AF EB 03 2D 00 00 00 E9 79 ..S...=...-y how do I interprate the data from 0x00020180? > > > > Data length is limited to the range 0..8. If RTR is 1, there is no > > > actual data, but the length field can still be in the range 0..8. If RTR > > > is 0, the first "length" bytes of the data have valid data in them. > > > > Does this mean the record length is variable or the valid data in the > > fixed length record varies? > > The amount of valid data varies. > > By the way: If you're going to insist on reading the raw data yourself, Its shaping up that way. > you may find useful this list, of record numbers where the flight > computer rebooted and the value of 'jiffies' goes back to near zero. I > used it with csplit. > > 92407 > 93785 > 225588 > 745298 > 757639 > > Jamey > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.6 (GNU/Linux) > > iD8DBQFHQxKOp1aplQ4I9mURAv6AAJ98XE/4aYj2EVCxqYhRH5rjJnTU5QCfTf+C > uiVTAP4XgAvKk4Kepxbbjco= > =C7IC > -END PGP SIGNATURE- signature.asc Description: Digital signature ___ psas-software mailing list psas-software@lists.psas.pdx.edu http://lists.psas.pdx.edu/mailman/listinfo/psas-software
Re: [psas-software] [PSAS] some data analysis from the 2005 launch
On Tue, Nov 20, 2007 at 10:52:08AM -0800, Andrew Greenberg wrote: > > So what was the dead on sample rate of the IMU packets? > > 2.5 ksps for the X, Y, Z and XY accelerometers > 833 Hz for the roll, pitch and yaw gyros. > > > When will the next meeting be? This is Thanksgiving week you know. > > Huh. I'd say next Wednesday, but Maria is calling for a movie night > during dead week it might be 11/28, but probably more realistically > 12/5. 12/5 works well for me too :) > > Andrew > > -- > > --- >Andrew Greenberg - [EMAIL PROTECTED] - 503.788.1343 > --- signature.asc Description: Digital signature ___ psas-software mailing list psas-software@lists.psas.pdx.edu http://lists.psas.pdx.edu/mailman/listinfo/psas-software
Re: [psas-software] [PSAS] some data analysis from the 2005 launch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/20/07, Andrew Greenberg <[EMAIL PROTECTED]> wrote: > Huh. So, I want to look at that. I really thought we solved this > problem before flight, so I think we should all sit down and make sure > the post-processing isn't missing something. I swear the ADEOS patch > fixed all this junk. The ADEOS patch ensured that we didn't lose any packets while reading them off the CAN bus from the microcontrollers. However, in that interrupt handler, we sampled the value of 'jiffies', which was incremented by the timer interrupt. We could have pulled the timer interrupt into the real-time ADEOS domain, but didn't--so the timer interrupt didn't get to execute any more than anything else when the IDE driver had interrupts disabled for long periods. That means that all messages received in those intervals where interrupts were disabled(-ish, cf. ADEOS) have the same, stale, timestamp; then the timer handler gets to run again, fast-forwards jiffies to catch up, and the next message received has a correct timestamp again. This kind of crap is why I don't want to fly a 2.4 kernel again. > Anyway: happy processing! See you all at the next meeting. Which I believe is a week from tomorrow. :-) Jamey -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHQxV8p1aplQ4I9mURAlhiAJ9jHWap3orvuAWXZ2NLfcw4IUR64ACfWeit v3QCkU7luqGV53eJ1RQdeQ4= =PZBM -END PGP SIGNATURE- ___ psas-software mailing list psas-software@lists.psas.pdx.edu http://lists.psas.pdx.edu/mailman/listinfo/psas-software
Re: [psas-software] [PSAS] some data analysis from the 2005 launch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/20/07, mark gross <[EMAIL PROTECTED]> wrote: > On Thu, Nov 15, 2007 at 10:11:02AM -0800, Jamey Sharp wrote: > > 4-byte big-endian "ID" > > 4-byte big-endian timestamp > > 8 bytes of data > > OK, so now looking at the Rocketview_20050820.log using hexedit which lists > out the data in 18 byte chunks. You meant 16, surely. > I'm not seeing the above record format ... `hexdump -v 20050820.log` shows me one sensible-looking message per line, though AFAICT it treats the input as native-endian and can't be forced to big-endian. > > Data length is limited to the range 0..8. If RTR is 1, there is no > > actual data, but the length field can still be in the range 0..8. If RTR > > is 0, the first "length" bytes of the data have valid data in them. > > Does this mean the record length is variable or the valid data in the > fixed length record varies? The amount of valid data varies. By the way: If you're going to insist on reading the raw data yourself, you may find useful this list, of record numbers where the flight computer rebooted and the value of 'jiffies' goes back to near zero. I used it with csplit. 92407 93785 225588 745298 757639 Jamey -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHQxKOp1aplQ4I9mURAv6AAJ98XE/4aYj2EVCxqYhRH5rjJnTU5QCfTf+C uiVTAP4XgAvKk4Kepxbbjco= =C7IC -END PGP SIGNATURE- ___ psas-software mailing list psas-software@lists.psas.pdx.edu http://lists.psas.pdx.edu/mailman/listinfo/psas-software
Re: [psas-software] [PSAS] some data analysis from the 2005 launch
On Thu, Nov 15, 2007 at 10:11:02AM -0800, Jamey Sharp wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 11/15/07, mark gross <[EMAIL PROTECTED]> wrote: > > Is there a format specification for the packed 16 byte array of data? I > > would like to check the text dumps. > > You don't trust me? ;-) The text dump I provided contains every bit of > information that has a defined meaning in the binary telemetry, unless > you want the timestamps of all the fragments of the big GPS messages, or > you want stuff from before the last time we turned on the flight > computer. I don't see any way that either of those are useful. It > discards bytes that are uninitialized, but we're trying to do data > analysis here, not fuzzing... > > But here's the format: > > 4-byte big-endian "ID" > 4-byte big-endian timestamp > 8 bytes of data OK, so now looking at the Rocketview_20050820.log using hexedit which lists out the data in 18 byte chunks. I'm not seeing the above record format, is there some variable length thing going on? > > The ID is a packed bitfield, with only the low 16 bits being > significant. The least significant 4 bits are the "data length", the > next bit is "RTR", and the remaining 11 bits are what CAN calls the > message ID. > > Data length is limited to the range 0..8. If RTR is 1, there is no > actual data, but the length field can still be in the range 0..8. If RTR > is 0, the first "length" bytes of the data have valid data in them. > Does this mean the record length is variable or the valid data in the fixed length record varies? > > Also, the time stamp data in the acceleration is not high enough > > resolution to be unique. > > Nope. We used the value of "jiffies" for each timestamp. We flew a 2.4 > kernel, so HZ was 100. > > You can reasonably assume that the IMU had a good clock, so > reconstructing higher-precision timestamps isn't that hard. You could > similarly reconstruct the timestamps of messages that originated in the > flight computer or on the ground, if desired. > > > ... the perl code git snapshot ... doesn't run to completion > > Hmmm, it Works For Me (tm). It does need to be able to seek on its > input, so don't feed it a pipe. > > > I wrote a python program to average the acc values for the items with > > the same time stamp and make a plot. (see attached) > > Interesting, thanks! > > Jamey > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.6 (GNU/Linux) > > iD8DBQFHPIutp1aplQ4I9mURAhXoAJ9QD7mdvmjwppRft285TVSLgVlntQCaAzyk > B8cqYXt7eiOOlQSKpmUr+7o= > =+OoI > -END PGP SIGNATURE- signature.asc Description: Digital signature ___ psas-software mailing list psas-software@lists.psas.pdx.edu http://lists.psas.pdx.edu/mailman/listinfo/psas-software
Re: [psas-software] [PSAS] some data analysis from the 2005 launch
On Tue, Nov 20, 2007 at 04:01:24AM -0800, Andrew Greenberg wrote: > Hi Mark, > > > did you find out how fast you could get away with sampling the various > > devices? I have some robot applications where I found that if I sample > > the data too fast I get different result than if I give things a chance > > to settle. Its a function of the device you are measuring. > > We *very* carefully chose the sample rates for all of our inertial > sensors on that IMU. You can argue whether or not they're optimal, but > they're definitely not too fast. They've got solid anti-aliasing filters > on them, and the whole system was designed off the noise floor of the > sensors. > > Also, we very carefully examed the raw data coming off the IMU (in terms > of CAN packets) before flight, and it was just what we expected. So I > don't think there's anything wrong with the IMU. > > > have done the actual sampling at a very regular interval. It was just a > > micro-controller, and had low latencies in its timer interrupt handler. > > I believe Andrew tested that with a good oscilloscope. > > Yep, I did, and it was dead on. So what was the dead on sample rate of the IMU packets? > > >> I'm sure it did, at one point, but once everything was integrated and > >> additional data was put on the CAN bus I'm thinking things where > >> different. > > CAN packets are transmitted based on their message ID, so they can get > all out of order. That's half of the "fun" of CAN :/ Hmm, that could be something to look at in the post processing. > > >> So before lift off the data seems to come once a jiffie, after launch I > >> get 25ish samples per jiffie (most times) with spikes of 70 and lows of > >> 1. How do I infer a uniform time per sample? > > Huh. So, I want to look at that. I really thought we solved this problem > before flight, so I think we should all sit down and make sure the > post-processing isn't missing something. I swear the ADEOS patch fixed > all this junk. > > Anyway: happy processing! See you all at the next meeting. When will the next meeting be? This is Thanksgiving week you know. --mgross signature.asc Description: Digital signature ___ psas-software mailing list psas-software@lists.psas.pdx.edu http://lists.psas.pdx.edu/mailman/listinfo/psas-software
Re: [psas-software] [PSAS] some data analysis from the 2005 launch
Hi Mark, > did you find out how fast you could get away with sampling the various > devices? I have some robot applications where I found that if I sample > the data too fast I get different result than if I give things a chance > to settle. Its a function of the device you are measuring. We *very* carefully chose the sample rates for all of our inertial sensors on that IMU. You can argue whether or not they're optimal, but they're definitely not too fast. They've got solid anti-aliasing filters on them, and the whole system was designed off the noise floor of the sensors. Also, we very carefully examed the raw data coming off the IMU (in terms of CAN packets) before flight, and it was just what we expected. So I don't think there's anything wrong with the IMU. > have done the actual sampling at a very regular interval. It was just a > micro-controller, and had low latencies in its timer interrupt handler. > I believe Andrew tested that with a good oscilloscope. Yep, I did, and it was dead on. >> I'm sure it did, at one point, but once everything was integrated and >> additional data was put on the CAN bus I'm thinking things where >> different. CAN packets are transmitted based on their message ID, so they can get all out of order. That's half of the "fun" of CAN :/ >> So before lift off the data seems to come once a jiffie, after launch I >> get 25ish samples per jiffie (most times) with spikes of 70 and lows of >> 1. How do I infer a uniform time per sample? Huh. So, I want to look at that. I really thought we solved this problem before flight, so I think we should all sit down and make sure the post-processing isn't missing something. I swear the ADEOS patch fixed all this junk. Anyway: happy processing! See you all at the next meeting. Andrew -- --- Andrew Greenberg Portland State Aerospace Society (http://psas.pdx.edu/) [EMAIL PROTECTED] P: 503.788.1343 C: 503.708.7711 --- ___ psas-software mailing list psas-software@lists.psas.pdx.edu http://lists.psas.pdx.edu/mailman/listinfo/psas-software
Re: [psas-software] [PSAS] some data analysis from the 2005 launch
On Fri, Nov 16, 2007 at 08:46:07AM -0800, Jamey Sharp wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 11/16/07, mark gross <[EMAIL PROTECTED]> wrote: > > are the a2d samples 2 or one byte each? (I'm assuming you where using > > a 10bit cheap A2D to take the measurements) > > Two bytes, yes; the ADCs were 12-bit. I expect they *were* cheap, > though, as you say. :-) did you find out how fast you could get away with sampling the various devices? I have some robot applications where I found that if I sample the data too fast I get different result than if I give things a chance to settle. Its a function of the device you are measuring. > > > The x,y acceleration data is very noisy. ... Given that the Z data is > > reasonable its likely the data is just too noisy all buy itself. > > The X/Y accelerometer pair are on a different scale than the Z/Q pair. > Is the noise still significantly different after you convert to common > units? > > > Some one should run the x/y acceleration data through and FFT to see > > if there are any acoustical effects getting sampled. > > Please do! :-) This weekend. > > > On Thu, Nov 15, 2007 at 10:11:02AM -0800, Jamey Sharp wrote: > > > You can reasonably assume that the IMU had a good clock, so > > > reconstructing higher-precision timestamps isn't that hard. You > > > could similarly reconstruct the timestamps of messages that > > > originated in the flight computer or on the ground, if desired. > > > > Umm, no. I cant. > > Yes, you can. ;-) The timestamps were computed by the flight computer; > explanation of those issues is below. But the IMU can be expected to > have done the actual sampling at a very regular interval. It was just a > micro-controller, and had low latencies in its timer interrupt handler. > I believe Andrew tested that with a good oscilloscope. I'm sure it did, at one point, but once everything was integrated and additional data was put on the CAN bus I'm thinking things where different. So before lift off the data seems to come once a jiffie, after launch I get 25ish samples per jiffie (most times) with spikes of 70 and lows of 1. How do I infer a uniform time per sample? > > You do have to account for dropped packets though. Since the flash disk > on the rocket was destroyed, this log comes from what we captured over > wi-fi, and while that's incredibly good, it isn't perfect. form just the data I can see I can't say its good even if I assume the time stamp is bogus and use sample index as a type of clock. I'll look at the data again from this point of view this weekend to see if I can see something different. > > Looking at the time stamp data it seems to change in the number > > samples taken per jiffy a lot. I see data with between 1 and 69 > > IMU_ACCELL_DATA records per jiffies. (look at time stamps 1931.90, > > 1931.91 for example) > > > > Attached is a plot of the count of IMU_ACCELL_DATA records per unique > > time stamp in the file. It doesn't look good (but hay there are some > > interesting periodicities in it, could point to where some of the > > problems are). > > I can't tell from your graph, but once the spikes become periodic, > they're about 5.3 seconds apart, right? And that starts about 38 seconds > after the data rate kicks up to full speed? > I'll get this information this weekend. --mgross > We measured this before the flight, but weren't able to implement a fix > in time. Our hypothesis is that whenever the flash disk we were logging > to flushed its write buffers, the kernel would hang until it was done. > It wasn't even handling interrupts during that interval, which lasted > about a quarter of a second, as I recall. We had to apply the ADEOS > patch to collect raw data packets from the CAN controller before its > buffers overflowed. We could have used ADEOS to make the timer interrupt > reliable too, and perhaps higher-frequency, but didn't get to it. > > Ignoring those spikes, the spread of messages-per-jiffy is still a > little larger than I'd have expected. I'm not sure what explains that, > off-hand, if you really did only plot IMU_ACCEL_DATA messages. > > Jamey > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.6 (GNU/Linux) > > iD8DBQFHPclJp1aplQ4I9mURAjitAJ40iGFwfdSkE+7nLKV1lC5n38jxwQCeKjro > YmUGg2Lu2IWQs85iYL8qgKA= > =yU03 > -END PGP SIGNATURE- signature.asc Description: Digital signature ___ psas-software mailing list psas-software@lists.psas.pdx.edu http://lists.psas.pdx.edu/mailman/listinfo/psas-software
Re: [psas-software] [PSAS] some data analysis from the 2005 launch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/16/07, mark gross <[EMAIL PROTECTED]> wrote: > are the a2d samples 2 or one byte each? (I'm assuming you where using > a 10bit cheap A2D to take the measurements) Two bytes, yes; the ADCs were 12-bit. I expect they *were* cheap, though, as you say. :-) > The x,y acceleration data is very noisy. ... Given that the Z data is > reasonable its likely the data is just too noisy all buy itself. The X/Y accelerometer pair are on a different scale than the Z/Q pair. Is the noise still significantly different after you convert to common units? > Some one should run the x/y acceleration data through and FFT to see > if there are any acoustical effects getting sampled. Please do! :-) > On Thu, Nov 15, 2007 at 10:11:02AM -0800, Jamey Sharp wrote: > > You can reasonably assume that the IMU had a good clock, so > > reconstructing higher-precision timestamps isn't that hard. You > > could similarly reconstruct the timestamps of messages that > > originated in the flight computer or on the ground, if desired. > > Umm, no. I cant. Yes, you can. ;-) The timestamps were computed by the flight computer; explanation of those issues is below. But the IMU can be expected to have done the actual sampling at a very regular interval. It was just a micro-controller, and had low latencies in its timer interrupt handler. I believe Andrew tested that with a good oscilloscope. You do have to account for dropped packets though. Since the flash disk on the rocket was destroyed, this log comes from what we captured over wi-fi, and while that's incredibly good, it isn't perfect. > Looking at the time stamp data it seems to change in the number > samples taken per jiffy a lot. I see data with between 1 and 69 > IMU_ACCELL_DATA records per jiffies. (look at time stamps 1931.90, > 1931.91 for example) > > Attached is a plot of the count of IMU_ACCELL_DATA records per unique > time stamp in the file. It doesn't look good (but hay there are some > interesting periodicities in it, could point to where some of the > problems are). I can't tell from your graph, but once the spikes become periodic, they're about 5.3 seconds apart, right? And that starts about 38 seconds after the data rate kicks up to full speed? We measured this before the flight, but weren't able to implement a fix in time. Our hypothesis is that whenever the flash disk we were logging to flushed its write buffers, the kernel would hang until it was done. It wasn't even handling interrupts during that interval, which lasted about a quarter of a second, as I recall. We had to apply the ADEOS patch to collect raw data packets from the CAN controller before its buffers overflowed. We could have used ADEOS to make the timer interrupt reliable too, and perhaps higher-frequency, but didn't get to it. Ignoring those spikes, the spread of messages-per-jiffy is still a little larger than I'd have expected. I'm not sure what explains that, off-hand, if you really did only plot IMU_ACCEL_DATA messages. Jamey -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHPclJp1aplQ4I9mURAjitAJ40iGFwfdSkE+7nLKV1lC5n38jxwQCeKjro YmUGg2Lu2IWQs85iYL8qgKA= =yU03 -END PGP SIGNATURE- ___ psas-software mailing list psas-software@lists.psas.pdx.edu http://lists.psas.pdx.edu/mailman/listinfo/psas-software
Re: [psas-software] [PSAS] some data analysis from the 2005 launch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/15/07, mark gross <[EMAIL PROTECTED]> wrote: > Is there a format specification for the packed 16 byte array of data? I > would like to check the text dumps. You don't trust me? ;-) The text dump I provided contains every bit of information that has a defined meaning in the binary telemetry, unless you want the timestamps of all the fragments of the big GPS messages, or you want stuff from before the last time we turned on the flight computer. I don't see any way that either of those are useful. It discards bytes that are uninitialized, but we're trying to do data analysis here, not fuzzing... But here's the format: 4-byte big-endian "ID" 4-byte big-endian timestamp 8 bytes of data The ID is a packed bitfield, with only the low 16 bits being significant. The least significant 4 bits are the "data length", the next bit is "RTR", and the remaining 11 bits are what CAN calls the message ID. Data length is limited to the range 0..8. If RTR is 1, there is no actual data, but the length field can still be in the range 0..8. If RTR is 0, the first "length" bytes of the data have valid data in them. > Also, the time stamp data in the acceleration is not high enough > resolution to be unique. Nope. We used the value of "jiffies" for each timestamp. We flew a 2.4 kernel, so HZ was 100. You can reasonably assume that the IMU had a good clock, so reconstructing higher-precision timestamps isn't that hard. You could similarly reconstruct the timestamps of messages that originated in the flight computer or on the ground, if desired. > ... the perl code git snapshot ... doesn't run to completion Hmmm, it Works For Me (tm). It does need to be able to seek on its input, so don't feed it a pipe. > I wrote a python program to average the acc values for the items with > the same time stamp and make a plot. (see attached) Interesting, thanks! Jamey -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHPIutp1aplQ4I9mURAhXoAJ9QD7mdvmjwppRft285TVSLgVlntQCaAzyk B8cqYXt7eiOOlQSKpmUr+7o= =+OoI -END PGP SIGNATURE- ___ psas-software mailing list psas-software@lists.psas.pdx.edu http://lists.psas.pdx.edu/mailman/listinfo/psas-software
Re: [psas-software] [PSAS] some data analysis from the 2005 launch and gyros
I'm doing fairly well with the log. I have gps location,accel,gyros,pressure and time read into VTK in their native units. I'm now looking for the calibration data to make the data presentable. Jamey says the acceleration and pressure calibration are in the flight computer code, but I have to bug someone else(Andrew) about the gyro data. So far this is what I've got. -- Sometimes it's hard to tell the dancer from the dance - Corwin in CoC <>___ psas-software mailing list psas-software@lists.psas.pdx.edu http://lists.psas.pdx.edu/mailman/listinfo/psas-software
Re: [psas-software] [PSAS] some data analysis from the 2005 launch
On Wed, Nov 07, 2007 at 11:40:00PM -0800, Jamey Sharp wrote: > Soon (three days?) after our 2005 flight, Eric Anholt sat down with > Andrew to answer some initial questions using the telemetry data we > captured. Their report is logged on the wiki, currently here: > > http://psas.pdx.edu/news/2005-08-20/data/ > > Unfortunately, we've done very little with the 40MB telemetry log > since then, though Larry made a good effort in mid-2006. (For some > reason he listened to me when I said he should use my Haskell code. > Bad idea, Larry: don't listen to me.) > Yay!, I've been looking for this data. There are a number analyzes I've been wanting to try on it. > I picked this work up again several weeks ago, and I've just updated > Larry's wiki page with my results: > > http://psas.pdx.edu/DataAnalysis/ > > There are some new pretty graphs. And if you want to do your own > analysis, you have a choice of two text formats for the telemetry > data. Both formats are much more accessible than the packed 16-byte > binary records that we recorded from the rocket. :-) binary isn't that hard to work with either. > > Please, if you have any interest in studying this data, or have some > questions you want to answer or ideas for neat graphs to make, come > discuss it on the psas-software mailing list. Or just have at the data > and tell us what you come up with. :-) Ok, I will. --mgross > > Jamey > > p.s. I showed all this to several folks a couple of weeks ago--no, > there's nothing new since then. > > ___ > psas-all mailing list > [EMAIL PROTECTED] > http://lists.psas.pdx.edu/mailman/listinfo/psas-all > > This list's membership is automatically generated from the memberships of the > psas-airframe, psas-avionics, psas-general, psas-payload, psas-propulsion, > and psas-software mail lists. Visit http://lists.psas.pdx.edu to individually > subscribe/unsubscribe yourself from these lists. signature.asc Description: Digital signature ___ psas-software mailing list psas-software@lists.psas.pdx.edu http://lists.psas.pdx.edu/mailman/listinfo/psas-software
