highaltitude.log.20090128

[00:34] smealum (n=smealum@smea.servebeer.com) left irc: Read error: 54 (Connection reset by peer)
[00:35] smealum (n=smealum@smea.servebeer.com) joined #highaltitude.
[00:55] hallam (i=836fc8c8@gateway/web/ajax/mibbit.com/x-f30b05e77ed6fb36) joined #highaltitude.
[00:57] <hallam> hey all
[00:57] <hallam> Laurenceb: could you give me some pseudoranges for my data set at the start of the nav frames?
[00:58] <hallam> actually brb
[01:55] <hallam> hey
[02:42] jiffe20 (n=jiffe@209.159.247.189) joined #highaltitude.
[03:37] <hallam> GOT A POSITION, YEAH BABY
[03:55] <SpeedEvil> :)
[03:57] hallam (i=836fc8c8@gateway/web/ajax/mibbit.com/x-f30b05e77ed6fb36) left irc: "http://www.mibbit.com ajax IRC Client"
[04:03] fergusnoble (n=fergusno@natreg.pem.cam.ac.uk) left irc: Read error: 104 (Connection reset by peer)
[04:03] hallam (i=836fc8c8@gateway/web/ajax/mibbit.com/x-e3ca00f8f87b5bf7) joined #highaltitude.
[04:25] Simon-MPFH (n=simon@phantom.mpfh.co.uk) joined #highaltitude.
[05:07] Nick change: hallam -> hallam|sleep
[05:11] hallam|sleep (i=836fc8c8@gateway/web/ajax/mibbit.com/x-e3ca00f8f87b5bf7) left irc: "http://www.mibbit.com ajax IRC Client"
[06:44] akawaka (n=akawaka@66-215-97-198.dhcp.malb.ca.charter.com) left irc: Read error: 110 (Connection timed out)
[07:05] Simon-MPFH (n=simon@phantom.mpfh.co.uk) left irc: "Leaving"
[07:33] edmoore (n=edmoore@pomegranate.chu.cam.ac.uk) joined #highaltitude.
[07:36] <edmoore> got an email with a position lock at 3.40am from Henry
[07:36] <edmoore> that child...
[08:26] M0TEK (n=ed@chu-gw.churchillcambridge.co.uk) joined #highaltitude.
[08:52] jcoxon (n=jcoxon@host86-158-31-172.range86-158.btcentralplus.com) joined #highaltitude.
[08:52] <jcoxon> wow
[08:52] <jcoxon> the first time in quite a few days the logs don't have Laurenceb and hallam chatting all night about GPS modules!
[08:54] <M0TEK> but i did get an email at 3.30 from hallam with a position fix!
[08:54] <M0TEK> so I assume it's worked
[08:56] <jcoxon> o[03:37] <hallam> GOT A POSITION, YEAH BABY
[08:56] <jcoxon> i guess it brings the marathon hacking session to an end
[08:56] <jcoxon> wow its pretty damn impressive
[08:57] Action: jcoxon has got some plaster of paris - now time to make his sugar glass champagne bottles
[09:05] <jcoxon> yes i have the day off :-p
[09:13] rharrison (n=rharriso@gateway.hgf.com) joined #highaltitude.
[09:14] <rharrison> Moring jcoxon
[09:14] <rharrison> ed
[09:14] <jcoxon> hey rharrison
[09:14] <rharrison> Laurenceb etc...
[09:14] <rharrison> How's it all going
[09:14] <edmoore> rharrison: hi
[09:15] <edmoore> not bad
[09:15] <rharrison> we're still having alot of GPS talk on here. The CUSF guys have gone a long way to making a soft GPS
[09:15] <edmoore> I think henry got a position fix on the gps last night
[09:15] <edmoore> i think it's not completed
[09:15] <edmoore> now*
[09:15] <rharrison> wow cool
[09:15] <edmoore> henry emailed at 3.30 with just a set of co-ordinates
[09:16] <edmoore> and then I assume passed out when he reliased how much degree he now has to catch up on
[09:16] <rharrison> haha
[09:16] <rharrison> Some one should have done their phd in GPS
[09:17] <edmoore> Laurenceb: is!
[09:17] <edmoore> well, the future of it anyway
[09:17] <rharrison> They have done well though. It's been quite interesting listening occasionally to the chatter. To be fair most of it was over my head
[09:18] <rharrison> Oh we're a patenting a new GPS protocol for the European version of GPS
[09:18] <rharrison> are
[09:18] <edmoore> it's an impressive thing to aquire and track the sats. I guess now the challenge is in optimisation and miniaturisation
[09:19] <rharrison> I work for a patent company
[09:20] <edmoore> any neat additions?
[09:20] <rharrison> Yep it was impressive. There is a book on SF with the blue box but I don't think I'll be playing with that any time soon
[09:21] <edmoore> the blue box is what we have
[09:21] <rharrison> TBH I havent even had a look at the patent specification but I gather more sats in less bandwidth.
[09:22] <edmoore> cool
[09:28] M0TEK (n=ed@chu-gw.churchillcambridge.co.uk) left irc: Read error: 110 (Connection timed out)
[09:29] Nick change: rharrison -> rjharrion_quiet
[10:04] jcoxon (n=jcoxon@host86-158-31-172.range86-158.btcentralplus.com) left irc: "This computer has gone to sleep"
[11:36] M0TEK (n=ed@chu-gw.churchillcambridge.co.uk) joined #highaltitude.
[11:37] <M0TEK> test
[11:40] <rjharrion_quiet> it worked
[11:40] <M0TEK> cool
[11:40] <M0TEK> dodgy wireless and unhelpful xchat
[11:41] <rjharrion_quiet> I'm hoping to launch w/e after next so get your audio cable ready
[11:42] <rjharrion_quiet> going for 50k this time NOT!
[11:43] <M0TEK> we might be doing this one
[11:48] <rjharrion_quiet> You guys ready for a lunch of some description or are you still in dev.
[11:52] <M0TEK> we can probably do a normal balloon launch
[11:52] <M0TEK> doubt any of the new stuff will be flying. but I don't know
[11:53] jcoxon (n=jcoxon@host86-158-31-172.range86-158.btcentralplus.com) joined #highaltitude.
[11:54] <rjharrion_quiet> Hi jcoxon If weather permitting are you going to be arround for a lunch next w/e?
[11:54] Action: rjharrion_quiet thinking tracking
[11:56] <jcoxon> 7/8?
[11:56] <rjharrion_quiet> Yep
[11:56] <rjharrion_quiet> that one
[11:57] <jcoxon> ummmm nothing on the calander
[11:57] <rjharrion_quiet> Sorry not very clear
[11:57] <M0TEK> tempting weathery fate?
[11:57] <jcoxon> though not sure if i'll be able to come up
[11:57] <rjharrion_quiet> If you can play god and sort the weather. I'll chase steve and see how he's set
[11:58] <M0TEK> i need to ping steve again re: balloons
[11:58] <rjharrion_quiet> M0TEK: True, we must be due the perfect winter high
[12:00] <rjharrion_quiet> I have 2E0 this w/e but the weather looks like it's going to be crap anyhow
[12:01] <M0TEK> have you had a look at sunday?
[12:01] <M0TEK> it's totally pink
[12:01] <rjharrion_quiet> IS that good or bad?
[12:01] <rjharrion_quiet> Probably good
[12:01] <jcoxon> oh this weekend is nice
[12:01] <M0TEK> how can you do ballooning and not use wunderground :p
[12:02] <jcoxon> M0TEK, he makes me look for him
[12:02] <rjharrion_quiet> I have a better souse
[12:02] <rjharrion_quiet> source
[12:02] <rjharrion_quiet> hehe
[12:02] <jcoxon> and flatters me in the process
[12:02] <M0TEK> show]
[12:02] <jcoxon> my weather ego is massive
[12:02] <rjharrion_quiet> That last launch jcoxon did better tracking than the onboard GPS
[12:03] <jcoxon> rjharrion_quiet, the weather this weekend is good - both sat and sun though sun is beter
[12:03] <jcoxon> and there won't be any rain either
[12:03] <rjharrion_quiet> Humm this w/e is too soon.
[12:04] <rjharrion_quiet> Dam
[12:04] <jcoxon> PATIENCE!
[12:04] <jcoxon> i'm sure it'll be good next weekend as well
[12:05] <rjharrion_quiet> Ok well that's settled then
[12:05] <rjharrion_quiet> :)
[12:05] <jcoxon> there is no use launching a rushed payload on a good day as you still aren't going to get it back
[12:06] <rjharrion_quiet> Oh I think the tracking working fine it's the on board experiments that need to be finalised
[12:07] <rjharrion_quiet> RX on 2m, external temp sensor etc...
[12:08] <jcoxon> Rx on 2m?
[12:08] <jcoxon> or 169?
[12:08] <rjharrion_quiet> 144 is 2M 168 1.74m?
[12:08] <jcoxon> just 2m is a rather specific band
[12:08] <rjharrion_quiet> ok :)
[12:09] <rjharrion_quiet> The antenna is alot bigger than 70cm's
[12:09] <jcoxon> how are you reading the Rx?
[12:09] <rjharrion_quiet> not sure how big I want to send up
[12:09] <rjharrion_quiet> MP3 recorder
[12:10] <M0TEK> cuspaceflight.co.uk/CUWS_talk.pdf
[12:10] <rjharrion_quiet> I plan to txt the TX'ed GPS from the 434 back to the 169
[12:11] <rjharrion_quiet> Greating a sort of loop with distance information on the MP3 to test range
[12:11] <rjharrion_quiet> Creating
[12:13] <M0TEK> talk we're doing if anyone's around
[12:13] <jcoxon> rjharrion_quiet, sounds like a good plan
[12:13] <rjharrion_quiet> nice PDF
[12:14] <rjharrion_quiet> Good use of call signs. Will let you off as seems to be wireless soc. involved :)
[12:15] <M0TEK> yeah, it's organised through the wireless society for the local ham groups
[12:15] <M0TEK> so we think we can get away with it
[12:25] jcoxon (n=jcoxon@host86-158-31-172.range86-158.btcentralplus.com) left irc: "Leaving"
[12:30] <rjharrion_quiet> Will you guys just do a lunch for fun soon. Seems a bit of a waste of time but good fun
[12:31] Action: SpeedEvil offers some ham slices as sponsorship.
[12:31] Action: rjharrion_quiet humm ham... I'm hungery
[12:46] M0TEK (n=ed@chu-gw.churchillcambridge.co.uk) left irc: Read error: 110 (Connection timed out)
[13:04] <SpeedEvil> Hmm. http://cgi.ebay.co.uk/ws/eBayISAPI.dll?ViewItem&item=150323346511 Easily modified into a polythene roll welder. Nice slow speed drive.
[13:22] gregHome (n=gleblanc@75.108.33.75) joined #highaltitude.
[13:30] M0TEK (n=ed@chu-gw.churchillcambridge.co.uk) joined #highaltitude.
[13:40] hallam (i=836f0142@gateway/web/ajax/mibbit.com/x-c3314b4366328f3a) joined #highaltitude.
[13:40] rjharrion_quiet (n=rharriso@gateway.hgf.com) left irc:
[13:41] <hallam> hi
[13:43] <hallam> Laurenceb / SpeedEvil: Any idea why a position fix would be off by about 100 meters?
[13:43] <hallam> also, Laurenceb: How did you get Borres' code to track sv32?
[13:44] <SpeedEvil> hallam: 100m tall antenna?
[13:44] <SpeedEvil> hallam: geoid problems?
[13:46] <hallam> not the first one (Laurenceb got a good fix from the same data set), pretty sure not the second - the cartesian-to-geodetic code has an option for which geoid to use and I tried all of them
[13:47] <SpeedEvil> 100m how off?
[13:47] <SpeedEvil> I know Laurenceb was moaning about having height off by about that
[13:47] <hallam> northwest
[13:47] <SpeedEvil> hmm
[13:47] <SpeedEvil> how are you verifying the coordinates?
[13:48] <hallam> google earth
[13:48] <SpeedEvil> check google maps
[13:48] <hallam> did
[13:49] <SpeedEvil> same?
[13:49] <hallam> yeah
[13:49] <hallam> I'm not using any information from one navigation fix to help the next
[13:49] <SpeedEvil> I know Laurenceb seemed to be happy with his lat/lon
[13:49] <hallam> but several randomly chosen points in time are all clustered around the same point with a few meters' spread
[13:50] <SpeedEvil> 300m would have a nice explanation
[13:50] <SpeedEvil> you've got 4 sats?
[13:50] <hallam> yep
[13:50] <hallam> one of which is a bit weak
[13:50] <SpeedEvil> I wonder if your code is worse affected by multipath for some reason
[13:51] <SpeedEvil> I'd wonder about fixing the alt, and trying fixes on 3 of the 4
[13:51] <hallam> the signal would be pretty weak after 100m of multipath, wouldn't it?
[13:51] <hallam> hm, that's worth a try
[13:51] <hallam> I'm very happy with it as a first attempt
[13:52] <SpeedEvil> Yeah - 100m/40000Km is damn good :)
[13:59] M0TEK (n=ed@chu-gw.churchillcambridge.co.uk) left irc: Read error: 110 (Connection timed out)
[14:09] Hiena (n=Hiena@81.93.195.181.datatrans.hu) joined #highaltitude.
[14:19] fergusnoble (n=fergusno@fn217.quns.cam.ac.uk) joined #highaltitude.
[14:19] <fergusnoble> hello
[14:19] <fergusnoble> edmoore: im guessing you got the email from henry
[14:20] <fergusnoble> very exciting
[14:20] <hallam> Hi Fergus
[14:21] <hallam> did you make your 9ams?
[14:22] <hallam> I've been reading Borres
[14:22] <hallam> it's a really good introduction but doesn't go into a ton of depth
[14:22] <hallam> e.g. no mention of carrier aiding
[14:25] <fergusnoble> hallam: no, didnt make any lectures
[14:25] <fergusnoble> for some reason i couldnt sleep until like 6am when i got back
[14:25] <hallam> oh, sorry to hear it
[15:04] <Laurenceb> hi everyone
[15:04] <SpeedEvil> Hello!
[15:04] <hallam> he hey
[15:04] <hallam> got a position fix last night :)
[15:04] <Laurenceb> nice
[15:05] <hallam> it's off by 100m though
[15:05] <Laurenceb> hmm
[15:05] <Laurenceb> one thing that confused me about borres code
[15:05] <Laurenceb> he uses the sample rate
[15:05] <Laurenceb> to find pseudoranges
[15:05] <Laurenceb> thats got to be wrong
[15:05] <hallam> err
[15:05] <hallam> yeah
[15:05] <hallam> I found my own pseudoranges
[15:06] <Laurenceb> it needs to be corrected by crystal offset
[15:06] <hallam> well I guess if he's measuring his bit transition times in samples, then you'll need the sample rate to find the pseudorange
[15:06] <hallam> 8183.8 / 8184?
[15:06] <Laurenceb> yeah
[15:06] <hallam> I already tried applying that everywhere I could think of
[15:06] <hallam> but the error is of that order
[15:06] <Laurenceb> I think this may explain the crazy oscillating fern thing I get
[15:07] <Laurenceb> each individual fix is 100m off or so
[15:07] <Laurenceb> with mine
[15:07] <hallam> hm
[15:07] <Laurenceb> have you tried averaging?
[15:07] <SpeedEvil> Ideal polythene welding machine. (needs some mods) http://cgi.ebay.co.uk/ws/eBayISAPI.dll?ViewItem&item=150323346511
[15:07] <hallam> I computed a few and they're all roughly the same place which is not where I live
[15:07] <Laurenceb> right
[15:07] <Laurenceb> how many ms in one position fix?
[15:08] <hallam> one
[15:08] <Laurenceb> hmm
[15:08] <hallam> I can't see how Borres code uses information from one to help the next.. does it?
[15:08] <Laurenceb> no
[15:08] <Laurenceb> it does 7 iterations
[15:08] <Laurenceb> on each interval
[15:08] <hallam> yeah
[15:08] <hallam> I tried increasing that, no difference
[15:08] <Laurenceb> then starts from scratch
[15:09] <Laurenceb> kind of silly
[15:09] <Laurenceb> right
[15:09] <hallam> and AFAICT in each interval it doesn't even average all the milliseconds in that interval
[15:09] <Laurenceb> yeah I got the best results from 1ms seamples
[15:09] <Laurenceb> yeah
[15:09] <Laurenceb> thats been confusing me
[15:09] <Laurenceb> he doesnt seem to average at all does he?
[15:09] <hallam> but Borres' code immediately gave the right position from my sample data?
[15:09] <hallam> not that I can see
[15:09] <Laurenceb> no
[15:10] <hallam> what did you have to do to get it?
[15:10] <Laurenceb> I had to rewrite acquisition
[15:10] <hallam> ok, I tried and it wasn't finding SV32 at all
[15:10] <hallam> so I guess I need to do that too
[15:10] <Laurenceb> yeah
[15:10] <hallam> but having done that, it worked?
[15:10] <Laurenceb> yes
[15:10] <hallam> maybe it's just that my tracking of SV32 is weak or something
[15:11] <hallam> I am using the output of the C program which makes all the approximations (square wave carrier etc)
[15:11] <Laurenceb> yeah, I modified borres code to do that
[15:11] <hallam> and 4MS/s
[15:12] <hallam> but I don't see that that should give consistently the wrong result
[15:12] <SpeedEvil> Laurenceb: did you fix the height problems you were having?
[15:12] <Laurenceb> did you calculate the satellite position correctly?
[15:12] <Laurenceb> SpeedEvil: yeah
[15:12] <Laurenceb> it wad the wrong geoid
[15:12] <SpeedEvil> :)
[15:13] <hallam> I used his satpos function
[15:14] <Laurenceb> yeah
[15:15] <Laurenceb> hmm
[15:15] <Laurenceb> did you put in the right time tho?
[15:15] <hallam> I think so
[15:15] <hallam> time of transmission from satellite
[15:15] <Laurenceb> hmm
[15:15] <Laurenceb> yeah I havent read through
[15:16] <hallam> the description in the book is pretty basic
[15:16] <Laurenceb> as I understand it the position of the sat is exactly defined by its ephermeris at the end of a suframe
[15:17] <Laurenceb> i.e. you have to take the difference in time between the current sample and the nearset end of a subframe
[15:17] <Laurenceb> and use that to find the position
[15:17] <hallam> hm
[15:17] <Laurenceb> the dt variable is a time differnece?
[15:17] <hallam> yeah
[15:18] <Laurenceb> hmm it just looks obfusticated to me
[15:18] <edmoore> fergusnoble: yep, got the email
[15:18] <edmoore> congratulations hallam
[15:18] <Laurenceb> do you use receiver tome or satellite time?
[15:18] <edmoore> you earn mega coolness points
[15:18] <edmoore> + Laurenceb
[15:18] <Laurenceb> something else that confuses me
[15:18] <Laurenceb> hi ed :P
[15:19] <edmoore> it was funny earlier, jcoxon came on saying 'oh my god, the first time in ages the logs havn't been full of hallam and laurenceb talking about gps'
[15:19] <Laurenceb> heh
[15:20] <hallam> hey ed
[15:20] <hallam> haha
[15:20] <hallam> sorry for taking over the channel a bit
[15:21] <hallam> Laurenceb: satellite time, for the satpos calculation - it makes sense
[15:21] <Laurenceb> yeah
[15:21] <Laurenceb> its receiver time?
[15:21] <hallam> but adding e.g. 0.1 seconds to the transmit time input to satpos does move the cluster quite a bit closer
[15:21] <hallam> it's not quite right though
[15:22] <Laurenceb> hmmm
[15:22] <Laurenceb> how are you finding pseudorange?
[15:23] <Laurenceb> it wont be quite right, there ionospheric correction and tropospheric
[15:24] <hallam> I thought their newton-raphson thing applied those
[15:25] <Laurenceb> Hallam: do you want to sell some of your samples?
[15:25] <hallam> ?
[15:25] <hallam> oh the sige
[15:25] <Laurenceb> apparently they are hard to obtain ;-)
[15:25] <hallam> I can give you one or two but yeah I want to keep most of them atm
[15:25] <Laurenceb> yeah, not for my use ;-)
[15:26] <Laurenceb> I'll email you nvm
[15:26] <hallam> ok
[15:26] <Laurenceb> not 100% sure yet
[15:27] <hallam> I find the pseudorange by recording the receive times of each PRN, in local clock, but accurate to better than one sample
[15:27] <hallam> hmm
[15:27] <hallam> I wonder what the local clock error is
[15:27] <hallam> should be that same factor, but I'll see
[15:29] <Laurenceb> this is all rather confusing
[15:29] <hallam> it's not too bad
[15:30] <hallam> the ECEF frame is a bit confusing I guess
[15:30] <Laurenceb> damn you einstein
[15:30] <hallam> inertial would be much more sensible
[15:31] <hallam> but pretty much you want to make sure you're computing the satellite positions based on when the signal left the satellite, and your position based on when it arrived at you
[15:31] <Laurenceb> yes
[15:32] <Laurenceb> basically I'm confused how you can do this without a receiver crystal drift term
[15:32] <Laurenceb> which appears to be absent in borres code
[15:33] <Laurenceb> hmm one sample is 75m
[15:34] <Laurenceb> how does borre improve the resolution?
[15:36] <Laurenceb> hmm it appears from the book that borre assumes ideal receiver clock
[15:36] <Laurenceb> and the you can calculate sat time and visa versa from the ephemeris
[15:38] <Laurenceb> page 121
[15:39] <Laurenceb> hmm you cant directly average pseudorange
[15:39] <Laurenceb> as it'll be changing too quickly
[15:39] <SpeedEvil> you can least-squares it
[15:40] <SpeedEvil> a polynomial fit
[15:40] <Laurenceb> hmm
[15:40] <Laurenceb> you can run at 1KHz :P
[15:40] hallam (i=836f0142@gateway/web/ajax/mibbit.com/x-c3314b4366328f3a) left irc: "http://www.mibbit.com ajax IRC Client"
[15:41] <Laurenceb> hallam?
[15:43] hallam (i=836fc8c8@gateway/web/ajax/mibbit.com/x-1c513b0678ed3f57) joined #highaltitude.
[15:43] <hallam> ok so it's easy enough to work out the time when the signal was transmitted
[15:43] <hallam> because the nav frame tells you, precisely
[15:44] <hallam> and if you want a nav solution offset from the start of a nav subframe you just add an integer number of ms, corresponding to the integer number of PRNs
[15:44] <hallam> then you don't care about the true arrival time, only the difference in arrival times between different sats
[15:45] <hallam> but it looks like a small error in that doesn't affect the position solution much
[15:45] <Laurenceb> hallam: borre is a bit more complex
[15:46] <Laurenceb> sat time != receiver time
[15:46] <Laurenceb> you have to do a correction
[15:47] <Laurenceb> hallam: time dilation
[15:48] <Laurenceb> p121
[15:50] <hallam> hmm
[15:50] <Laurenceb> also it seems borres code is only accurate to the nearest sample
[15:50] <Laurenceb> whic I think finally explains my fern leaf oscillation
[15:51] <Laurenceb> yeah I'm confused
[15:51] <Laurenceb> if you use sat time in sat position
[15:51] <Laurenceb> then you can count the number of prn codes transmitted from the nearest subframe end
[15:52] <Laurenceb> to work out the sat time
[15:54] <Laurenceb> oh bottom of the page
[15:54] <Laurenceb> t_common
[15:55] <Laurenceb> I think you use the fact your pseudorange measurements all come from transmissions at the same time
[15:56] <Laurenceb> in gps frame
[15:57] <hallam> is the relativity effect really on the scale of 100m?
[15:57] <Laurenceb> yeah may well be
[15:58] <hallam> hm, I think it might be doppler actually
[15:58] <hallam> er
[15:58] <hallam> argh
[15:58] <hallam> confusing
[15:59] <Laurenceb> yeah
[15:59] <Laurenceb> my head hurts
[16:01] <Laurenceb> ok, p118, sat pos uses gps time
[16:03] <Laurenceb> so you need to find sat positions at time of transmission
[16:03] <Laurenceb> you code stays aligned to each prn code
[16:03] <Laurenceb> so you can cound the number of prn code from the nearest subframe end
[16:04] <Laurenceb> giving you sat time directly
[16:05] Hiena (n=Hiena@81.93.195.181.datatrans.hu) left irc: "-=Halt! Hammerzeit!=-"
[16:07] <Laurenceb> so you can find the position of each sat
[16:07] <Laurenceb> then you can find pseudorange using time in samples
[16:07] <Laurenceb> I'd start off by just doing one position fix, at the end of a subframe
[16:08] <hallam> I am
[16:08] <Laurenceb> that way its easier to think about
[16:08] <Laurenceb> you know sat pos directly
[16:08] <hallam> right
[16:08] <Laurenceb> then find the relative ranges to the other sats in samples
[16:09] <Laurenceb> i.e. compare in samples to where their subframes end
[16:10] <Laurenceb> oh crap its ECEF
[16:10] <Laurenceb> so the earth is spinning
[16:12] <Laurenceb> hmm this is where is gets confusing
[16:12] <Laurenceb> you know where the st was
[16:12] <hallam> right, and that's all that matters, not where it is later
[16:13] <Laurenceb> ok
[16:13] <Laurenceb> if I'm on a train
[16:13] <Laurenceb> an two light pulses fire at once
[16:13] <hallam> the light doesn't know what happens to the satellite once it's left
[16:13] <Laurenceb> one in front, one behind
[16:13] <Laurenceb> what hits nme first?
[16:14] <Laurenceb> I think this is one of those weird relativity things
[16:15] <hallam> I don't think so
[16:15] <hallam> I don't think anything is going fast enough for special to be important
[16:15] <Laurenceb> it is for sure
[16:15] <hallam> I think the only relativity that could affect it is general, i.e. things due to the differing gravitational field
[16:15] <hallam> which I know little about
[16:15] <Laurenceb> sure, thats for clock correction
[16:16] <hallam> gamma is 10^-11
[16:16] <hallam> so I really don't think special is important
[16:16] <hallam> that's 6 microns in the radius of the earth
[16:17] <SpeedEvil> frame dragging.
[16:17] <hallam> right
[16:17] <Laurenceb> haha
[16:17] <hallam> general stuff
[16:17] <Laurenceb> no special
[16:17] <Laurenceb> is what I'm talking about
[16:17] <hallam> which means no lights and no trains
[16:17] <Laurenceb> erm no
[16:17] <Laurenceb> lights and trains is special
[16:18] <hallam> right
[16:18] <hallam> special effects go as (v/c)^2
[16:18] <hallam> which is 10^-11
[16:18] <hallam> which is fuck all, hence it's not important
[16:18] <Laurenceb> yeah
[16:18] <SpeedEvil> Doppler freq is ~10KHz ?
[16:18] <hallam> yeswithabut
[16:19] <Laurenceb> but do you have to consider earths rotation in thwe time it takes the light to reach us?
[16:19] <hallam> that's not relativity at all, just a coordinate transform
[16:19] <SpeedEvil> Aether corrections!
[16:20] <hallam> but they deal with that in either satpos or leastsquares, I forget which
[16:20] <hallam> leastsquares I think
[16:20] <Laurenceb> hmm
[16:21] <Laurenceb> yeah
[16:21] <Laurenceb> if you dont know where you are
[16:21] <Laurenceb> you dont know how much you'll have rotated
[16:21] <hallam> that's why it's in leastsquares
[16:23] <Laurenceb> isnt that a ctahc22?
[16:23] <Laurenceb> you dont know how much you will have moved
[16:24] <hallam> it just means you need to iterate
[16:24] <Laurenceb> oh hang on
[16:25] <hallam> ok I tried turning off the general correction and it changed the positions by <10m
[16:25] <Laurenceb> you work out time in ECEF frame
[16:25] <hallam> which is about what I expected
[16:25] <Laurenceb> p121 again
[16:25] <Laurenceb> tcommon as the time of transmission
[16:26] <Laurenceb> but you correctit
[16:27] <Laurenceb> a bit odd
[16:27] <Laurenceb> you find sat time in ECEF frame, using the time of observation
[16:28] <Laurenceb> then convert sat time to the gps frame
[16:28] <Laurenceb> there is another solution, maybe simpler to understand
[16:28] <Laurenceb> but differing from the book
[16:28] <Laurenceb> use an inertial frame
[16:29] <hallam> I don't put too much stock in the book
[16:29] <Laurenceb> find sat positions based on their subframe ends and counting prn code iterations
[16:29] <Laurenceb> in the inertial frame
[16:29] <Laurenceb> solve to find position in the inertial frame
[16:29] <Laurenceb> solve to find position and time in the inertial frame
[16:30] <Laurenceb> then move straight to lat long alt
[16:30] <Laurenceb> saves converting from ECEF to lat long alt as well
[16:30] <Laurenceb> i.e. its no more work
[16:31] <Laurenceb> at least it doesnt lead to brain explosion just thinking about it
[16:32] <Laurenceb> so the basic way would be: find subframe end, find sat position in inertial based on that
[16:32] <Laurenceb> then find the position of each of the tracked sats at their subframe ends
[16:32] <Laurenceb> then count time in terms of samples between each subframe end
[16:32] <Laurenceb> solve for position
[16:33] <Laurenceb> unfortunatley it cant solve for a dodgy crystal
[16:33] <Laurenceb> but I dont see that anywhere in borres
[16:33] <Laurenceb> you have to solve several times are find crystak drift
[16:34] <hallam> the way I see it
[16:35] <hallam> crystal shouldn't matter
[16:35] <Laurenceb> you can work out the earths rotation angle based on sat time and ephemeris equations
[16:35] <hallam> ok I'll try to explain
[16:35] <hallam> for satellite position at transmit time, crystal clearly doesn't matter, right?
[16:35] <Laurenceb> yeah
[16:35] <hallam> now
[16:35] <hallam> for the reception time, you don't really use the crystal at all
[16:36] <hallam> instead you track the PRN phase, accurate to better than a chip
[16:36] <Laurenceb> yes
[16:36] <hallam> so you're measuring the time difference of arrival in PRN chips
[16:36] <hallam> not in samples
[16:36] <Laurenceb> no
[16:36] <hallam> that's sourced from the clocks on the satellite
[16:36] <Laurenceb> in samples
[16:36] <hallam> ok look at it this way
[16:36] <Laurenceb> you have to measure delta time in samples
[16:37] <hallam> let's say you just counted the whole number of PRNs between nav bit edges of the different sats
[16:37] <hallam> obviously it would only be accurate to the nearest millisecond
[16:37] <hallam> but it would be based on the satellite's clock, not yours
[16:37] <hallam> right?
[16:37] <Laurenceb> yes
[16:37] <Laurenceb> but its doppler shifted
[16:37] <hallam> now let's say you count chips
[16:38] <Laurenceb> you count chips to work out sat position
[16:38] <Laurenceb> as you know sat position as a function of sat time
[16:38] <hallam> no, to work out difference in arrival time of the nav bit edge
[16:38] <hallam> not sat position
[16:38] <hallam> I *think* the doppler shift doesn't matter / is exactly what you're trying to measure
[16:38] Action: SpeedEvil thinks you're both furiously agreeing.
[16:39] <Laurenceb> yes, difference in arrival time in sampels
[16:39] <hallam> no
[16:39] <hallam> in chips
[16:39] <Laurenceb> you need an independant time dasis
[16:39] <Laurenceb> chips is dopplered
[16:39] <Laurenceb> *basis
[16:39] <hallam> not for the light it's not
[16:39] <Laurenceb> yeah
[16:39] <SpeedEvil> you don't - you can work the solution in terms of using one of the recieved satelites as your reference clock
[16:39] <Laurenceb> why do you have a DLL
[16:40] <Laurenceb> SpeedEvil: its code will be shifted
[16:40] <SpeedEvil> (averaged) - this almost certainly makes no sense though.
[16:40] <hallam> the DLL is what lets you get it accurate to better than a chip
[16:40] <Laurenceb> Borre uses samples
[16:40] <Laurenceb> ah using the discriminator output?
[16:40] <hallam> I know, but they're also using a much higher sample rate
[16:40] <hallam> sort of
[16:40] <Laurenceb> yeah
[16:40] <Laurenceb> arg
[16:41] <hallam> are you with me up to using whole PRNs?
[16:41] <Laurenceb> I'm going to have to correct borres code
[16:41] <Laurenceb> yes
[16:41] <Laurenceb> I know what your saying
[16:41] <hallam> and chips is just like that?
[16:41] <hallam> ok
[16:41] <Laurenceb> but it wont work
[16:41] <Laurenceb> chips are dopplered
[16:41] <Laurenceb> you need an independant time
[16:41] <hallam> it's what I'm doing
[16:41] <Laurenceb> ...
[16:41] <hallam> I'll try correcting the chips for doppler
[16:42] <hallam> but I don't think it's necessary
[16:42] <Laurenceb> erm ok...
[16:42] <Laurenceb> yeah that may work for stationary
[16:42] <Laurenceb> but if your moving your screwed
[16:42] <hallam> the TDOA is max 9ms
[16:42] <hallam> in 9ms even at Mach 4 you don't move much
[16:42] <Laurenceb> hmm
[16:43] <Laurenceb> I'm not sure about this
[16:43] <Laurenceb> most solution s derive a crystal drift
[16:43] <Laurenceb> in fact everything I've seen does
[16:44] <Laurenceb> but yeah if your stationary it may work
[16:44] <SpeedEvil> It seems to me you can use any clock you like. Including one of the satellites including doppler. As long as you can work out the relative drifts between that and the (other) satellites
[16:44] <Laurenceb> yeah
[16:45] <SpeedEvil> It doesn't matter if it's changing freq, as long as you can nail down enough terms to solve it accurately.
[16:45] <Laurenceb> it would work if your stationary
[16:45] <Laurenceb> maybe if your moving and have an imu
[16:45] <Laurenceb> but why
[16:45] <Laurenceb> when you have a nice little crystal
[16:46] <SpeedEvil> I have no idea why you might do this - especially as the crystal is likely to be lower jitter than the locally recieved sat signal
[16:46] <Laurenceb> yeah
[16:46] <Laurenceb> so... to you just work out the crystal drift
[16:46] <SpeedEvil> that seems the sane way
[16:46] <Laurenceb> by finding how the time term in least squares shifts
[16:47] <Laurenceb> right, I'm going to correct borres code now :P
[16:47] <Laurenceb> hallam: using the disc output to improve pseudorange is good though
[16:48] <Laurenceb> I think the fern pattern is a conbination of pseudorange jitter and crystal offset
[16:48] <SpeedEvil> Optimal GPS reception results in a buttercup.
[16:48] <Laurenceb> if I take the thinkness of the "leaves" as the noise in the solution, its about a meter :P
[16:48] <Laurenceb> hehe
[16:50] Action: hallam is no closer to figuring out why his positions are off
[16:51] <Laurenceb> I'd rewrite it from scratch
[16:51] <Laurenceb> have a play with borres code first
[16:51] <hallam> but it's so slow
[16:51] <Laurenceb> he
[16:51] <hallam> you have to wait 15 minutes every time you want to test something
[16:52] <Laurenceb> Issh into a faster machine
[16:52] <hallam> this one's plenty fast
[16:52] <hallam> Laurenceb: any luck integrating my C tracker with Borres?
[16:53] <Laurenceb> no, havent tried
[16:53] <Laurenceb> I was out last night
[16:53] <hallam> ok
[16:55] <hallam> I'm going to collect some more data, brb
[16:56] hallam (i=836fc8c8@gateway/web/ajax/mibbit.com/x-1c513b0678ed3f57) left irc: "http://www.mibbit.com ajax IRC Client"
[17:06] <Laurenceb> why does this make me think of super mario
[17:16] akawaka (n=akawaka@66-215-97-198.dhcp.malb.ca.charter.com) joined #highaltitude.
[17:23] <Laurenceb> hmm this is odd, smaple rate changes make no difference
[17:23] <Laurenceb> I guess least squares doesnt mind a % change in pseudorange differences
[17:32] hallam (i=836fc8c8@gateway/web/ajax/mibbit.com/x-eced4d68af989fe0) joined #highaltitude.
[17:35] <Laurenceb> hi hallam
[17:36] <Laurenceb> ok.. I tried changing the sample rate to the correct rate in the pseudorange calculation - it gives the same result almost
[17:36] <Laurenceb> about 2m difference
[17:36] <Laurenceb> very odd
[17:38] <hallam> right, that's what I thought
[17:38] <hallam> I'm going to try getting my pseudoranges based on absolute sample time
[17:38] <Laurenceb> but...
[17:38] <hallam> rewriting the C code a bit first tho
[17:39] <Laurenceb> if you scale the pseudoranges by something
[17:39] <Laurenceb> is shouldnt give the correct solution... should it?
[17:41] <hallam> no, but if the something is small then the error is also small
[17:42] <hallam> it also depends at what point you scale them
[17:42] <Laurenceb> hmm
[17:42] <hallam> e.g. if you set the closest sat to be 1 second away, then multiplying all the pseudoranges by 1.1 will produce a bigger absolute change than if you set the closest sat to be right next to you
[17:43] <Laurenceb> true
[17:43] <Laurenceb> its got to cause a few hundered meters change tho
[17:44] <Laurenceb> maybe the geometery is such that that doesnt muck up the results too much
[17:44] <Laurenceb> still - you can easily correct for crystal drift once you have a few solutions
[17:44] <Laurenceb> most receivers have second order crystal drift tracking
[17:45] <Laurenceb> the lassen iq certainly does
[17:48] <Laurenceb> hallam: did you record some data?
[17:49] <Laurenceb> hallam: any chance you could zip it and send me a copy
[17:54] Simon-MPFH (n=simon@phantom.mpfh.co.uk) joined #highaltitude.
[18:15] <hallam> Laurenceb: sure
[18:15] <hallam> I got one set with the ant against the window, and a few more with it in various EMI-prone situations
[18:16] <hallam> do you want the EMI ones or just the first?
[18:16] <Laurenceb> just the first thanks
[18:16] <Laurenceb> the EMI sounds interesting
[18:16] <hallam> yeah I haven't looked at it yet
[18:16] akawaka (n=akawaka@66-215-97-198.dhcp.malb.ca.charter.com) left irc: Read error: 110 (Connection timed out)
[18:17] <hallam> it's kind of impressive that .rar gets it under 2 bits per 2-bit IQ sample
[18:17] <fergusnoble> hallam: its strange its exactly the same order at the crystal error, that sounds like it could be the problem
[18:17] <hallam> fergusnoble: yeah, it's pretty confusing though
[18:18] <hallam> I have a trick or two left up my sleeve
[18:18] <hallam> I'd like to get the acq and nav into C too
[18:19] <Laurenceb> hallam: I'd try a kal,am filter approach
[18:20] <Laurenceb> brb
[18:23] natrium42 (i=natrium4@CPE000625d867e2-CM0014045885be.cpe.net.cable.rogers.com) joined #highaltitude.
[18:25] <Laurenceb> hallam: got your dvd
[18:26] <hallam> wow, it took long enough
[18:26] <hallam> so much for 1st class
[18:26] <hallam> anyway hope it serves you well
[18:26] <Laurenceb> well I dont check my mail very oftwen
[18:26] <Laurenceb> thanks
[18:26] <hallam> hehe, me neither
[18:27] <hallam> or I'd have read Borre last week
[18:27] <Laurenceb> looks like it arrived on monday
[18:27] <Laurenceb> borres finds pseudorange using position through the file
[18:28] <Laurenceb> so I've added a correction term based on the DLL discriminator
[18:28] <Laurenceb> to try and improve the resolution
[18:28] <Laurenceb> pity it takes so long to run
[18:29] <Laurenceb> also you cant c&p from different x windows
[18:29] natrium42 (i=natrium4@CPE000625d867e2-CM0014045885be.cpe.net.cable.rogers.com) left #highaltitude.
[18:30] <Laurenceb> makes things tedious
[18:31] <SpeedEvil> IIRC there are ways to get that to work
[18:31] <SpeedEvil> I've forgotten what it is though.
[18:31] Action: SpeedEvil sighs.
[18:31] <hallam> fergusnoble: I just discovered that more than half the time used by the tracking program is disk access
[18:31] <Laurenceb> yeah I'm using a debian workstation atm
[18:31] <hallam> so it's more like 14MHz/channel, and that without any asm optimisation
[18:32] <Laurenceb> nice
[18:32] <Laurenceb> fastrax claim 10MHz/channel on arm9
[18:32] natrium42 (n=alexei@CPE000625d867e2-CM0014045885be.cpe.net.cable.rogers.com) joined #highaltitude.
[18:32] <hallam> yeah
[18:32] <Laurenceb> annoyingly their module is still a prototype
[18:32] <Laurenceb> not for sale yet
[18:33] <Laurenceb> or we could reflash it
[18:33] <Laurenceb> - se4120 and arm9 bga
[18:36] <Laurenceb> hmm this hasnt entirely fixed the probme
[18:37] <Laurenceb> the fern pattern seems to have been mangled up a bit, and there more clustering near the middle
[18:37] <Laurenceb> standard deviation is probably 20m
[18:41] <Laurenceb> hardly any difference in position
[18:45] <hallam> borres is really only measuring pseudoranges to the nearest sample?
[18:45] <hallam> even at 8MS/s that's 36m
[18:47] <Laurenceb> yes
[18:47] <Laurenceb> I think I got the correction factor out by 4
[18:47] <Laurenceb> - out by a factor of 4
[18:47] <Laurenceb> here we go again :P
[18:47] <Laurenceb> 30minutes number crunching
[18:48] Hiena (n=Hiena@81.93.195.181.datatrans.hu) joined #highaltitude.
[18:49] <Laurenceb> its like some point got sucked off the fern pattern and ended up near the avergae position
[18:49] <Laurenceb> looks hopeful
[18:49] <Laurenceb> pseudorange quantisation is going to be amplified in position solutions in most cases with only 4 sats
[18:58] <hallam> hmmm
[18:58] <hallam> using the raw sample times doesn't make much difference
[19:00] <hallam> well
[19:00] <hallam> it spreads out the nav solutions over a much wider area, that now includes the true position
[19:00] <hallam> but the centroid of them is still where it was, which is the wrong place
[19:03] Bluenarf (n=Paul@apollo.paulsnet.org) joined #highaltitude.
[19:03] Nick change: Bluenarf -> EI5GTB
[19:03] <Laurenceb> hmm
[19:04] <Laurenceb> what do you mean by raw sample times?
[19:04] <hallam> the index into the data file that that PRN began at
[19:04] <Laurenceb> right
[19:05] <Laurenceb> PRN of subframe end?
[19:06] <Laurenceb> you want the index of the end of the subframes last prn
[19:07] rjharrison (n=rharriso@80.176.172.227) joined #highaltitude.
[19:08] <edmoore> hi rjharrison
[19:08] <rjharrison> yo ed
[19:08] <rjharrison> Soft GPS all go now then
[19:08] <rjharrison> I look forward to seeing that in action
[19:09] <Laurenceb> ;P
[19:10] <Laurenceb> hallam: yeah standard deviation is down to about 40m now
[19:10] <rjharrison> is that 40m accuracy
[19:10] <Laurenceb> and its roughly elliptical, but there still some quantisation noise
[19:10] <Laurenceb> no about 3m accuracy hopefully
[19:10] <hallam> Laurenceb: PRN of the subframe start
[19:10] <hallam> it's an edge
[19:10] <hallam> so it's the same as the end of the previous one
[19:11] <Laurenceb> yeha
[19:11] <Laurenceb> *yes
[19:11] <hallam> but the ICD spec calls for the time at the start of the next subframe
[19:11] <rjharrison> What's the best you can hope for standard GPS accuracy?
[19:11] <Laurenceb> about 3 or 4 meters
[19:11] <rjharrison> with out any limits
[19:11] <rjharrison> nice
[19:12] <Laurenceb> I really need an inverse equation for the decoherent discriminator to get any better atm
[19:12] <hallam> Laurenceb: just to check, what is the position you're getting out?
[19:12] <Laurenceb> but its a lot better than defone with the 150m + "fern leaves"
[19:12] <Laurenceb> just a sec
[19:13] <Laurenceb> 52 12' 7.4981'' N 0 7' 5.4272'' E
[19:13] <Laurenceb> thats the fern leaves solution
[19:15] <hallam> ok
[19:16] <Laurenceb> I'm getting within a meter of that with this new solution
[19:16] <Laurenceb> its probably the limit of what your going to get
[19:16] <Laurenceb> dont forget the building are really squewed over
[19:16] <Laurenceb> on google maps, so its only 4 meters out approx
[19:17] <hallam> yeah mine are definitely clustering somewhere that isn't there
[19:17] <SpeedEvil> I suppose one metric would be take a static survey point, and sample it every 3 hours or so, and see how stationary it is
[19:20] <hallam> http://uploads.mibbit.com/up/ZlO9b9m4.png
[19:20] <hallam> http://uploads.mibbit.com/up/bHkK3oiI.png
[19:21] <hallam> green is where I think it is on google maps (not very accurate), red is Laurenceb's fix
[19:21] <hallam> Black is the centroid of the fixes
[19:22] <hallam> or at least the mean lat/lon
[19:23] <edmoore> thanks hallam
[19:23] <hallam> you asked for it :P
[19:24] <hallam> (sorry, I will try to put some kind of useful comment in the future)
[19:24] <edmoore> np :p
[19:24] <Laurenceb> hmm
[19:24] <Laurenceb> they are clustered into lines
[19:24] <Laurenceb> looks like a quantisation problem
[19:25] <hallam> I don't think so
[19:25] <Laurenceb> but that doesnt explain the position being off
[19:25] <hallam> right
[19:25] <edmoore> what is this graph of?
[19:25] <hallam> nav solutions
[19:25] <hallam> lat/lon
[19:25] <edmoore> from one static sample?
[19:25] <edmoore> one static collection of data*
[19:26] <hallam> yeah
[19:26] <hallam> every 50ms over 30 seconds
[19:26] <Laurenceb> hmm
[19:26] <edmoore> what's the green and red ticks?
[19:26] <hallam> where it should be
[19:27] <edmoore> would you be able to save it as a csv and email it?
[19:27] <hallam> blue being where it thinks it is, and black the average of that
[19:27] <hallam> uh
[19:27] <hallam> if you really want
[19:27] <edmoore> i wouldn't mind if it's not too much bother
[19:27] <edmoore> but don't worry if it is
[19:27] <hallam> sure, I'll do that
[19:27] <fergusnoble> edmoore: what are you planning?
[19:27] <edmoore> an attack on the kremlin
[19:28] <fergusnoble> hallam, edmoore: we need to meet to plan out our talk
[19:28] <Laurenceb> whift is too big to be caused by earths rotation
[19:28] <edmoore> sure, though it is about 6 weeks away
[19:28] <Laurenceb> I think
[19:28] <Laurenceb> how far is it out? in meters
[19:29] <fergusnoble> hallam: how does it vary with time? randomly or is it moving in any one direction?
[19:29] <edmoore> also hallam, has this data been through the c-tracking code or is it all matlab?
[19:29] <edmoore> 20 questions
[19:29] <SpeedEvil> hallam said 100m or so earlier
[19:29] <Laurenceb> hmm
[19:29] <fergusnoble> edmoore, will have gone through the C
[19:29] <Laurenceb> earths rotation would be <30m
[19:29] <hallam> http://uploads.mibbit.com/up/SCmgYTK7.csv
[19:29] <edmoore> ok, that's useful to know
[19:29] <Laurenceb> but its in the right direction
[19:30] <hallam> ~100 meters out, went through the C tracker, there's short period and longer-period drifts
[19:30] natrium42 (n=alexei@CPE000625d867e2-CM0014045885be.cpe.net.cable.rogers.com) left irc:
[19:31] <fergusnoble> hallam: yeah just scanning the csv it looks like its heading west noisily
[19:32] <fergusnoble> brb
[19:34] <edmoore> gah hallam the csv precisions in insufficient
[19:34] <edmoore> in latitude
[19:34] natrium42 (n=alexei@CPE000625d867e2-CM0014045885be.cpe.net.cable.rogers.com) joined #highaltitude.
[19:34] <edmoore> it's all either .202 or .203
[19:34] <Laurenceb> hmm theres no ionospheric correction is there?
[19:35] <Laurenceb> but it shouldnt cause that much error
[19:35] <hallam> I don't think there's any in Borres either
[19:35] <hallam> I wonder if it's something to do with my DLL
[19:35] <hallam> edmoore: can give you a matlab file
[19:35] <edmoore> this is what I was thinking too
[19:36] <Laurenceb> I think its an error in the time business
[19:36] <edmoore> yeah that would be grand
[19:37] <hallam> http://uploads.mibbit.com/up/PPTzXJdE.mat
[19:38] <edmoore> thanks
[19:42] Hiena (n=Hiena@81.93.195.181.datatrans.hu) left irc: "-=Halt! Hammerzeit!=-"
[19:42] <hallam> well that's interesting
[19:42] <fergusnoble> hallam: what distance does an error of one subchip correspond to?
[19:42] <Laurenceb> so... I follow the pseudorange calculation bit
[19:42] <hallam> it depends
[19:42] <Laurenceb> but how do you work out the satellite positions?
[19:42] <hallam> with Borres' functions
[19:43] <Laurenceb> so what time do you use?
[19:43] <hallam> transmit time, of course
[19:43] <Laurenceb> yeah
[19:43] <Laurenceb> hmmm
[19:43] <hallam> fergusnoble: if I move the first satellite by one subchip in the right direction, the solution's almost perfect
[19:43] <Laurenceb> I dont see where the earth rotation comesin
[19:43] <hallam> it's taken care of in borres' leastsquares
[19:44] <hallam> of course moving them all by one subchip has no effect
[19:44] <fergusnoble> hallam: yes, so maybe its something in the acumulation of the eml result in the dll?
[19:44] <hallam> it might be the DLL itself
[19:45] <hallam> hmmmm
[19:45] <hallam> I wonder if it drifts off and then snaps back into place
[19:45] <Laurenceb> plot discriminator output
[19:47] <fergusnoble> hallam: when you say that if you move the first sat by one subship the solutions perfect do you mean that the black dot moves over to the correct place with the same spread?
[19:47] <Laurenceb> hallam: I dont see any correction in least squares
[19:48] <hallam> fergusnoble: yes
[19:48] <hallam> http://uploads.mibbit.com/up/exyrvX7t.png DLL discriminator
[19:49] <edmoore> re: dll error, wouldn't that alone affect lat and long position equally? Is it also a function of sat geometry? Basically, the spread in longitude is ~5x the spread in lattitude
[19:49] <hallam> func of sat geom
[19:49] <fergusnoble> hallam: if there was a dll error wouldnt that affect each sat by the same amount and so would cancel?
[19:50] <fergusnoble> or at least not lead to one sat being one subchip out
[19:50] <hallam> not necessarily
[19:50] <hallam> oh sure, I'm not saying one sat is one subchip out and the others are perfect
[19:51] <Laurenceb> hallam: what are the units?
[19:51] <hallam> pretty abritrary
[19:51] <hallam> ms on the bottom
[19:51] <Laurenceb> oh so its over a bin
[19:51] <Laurenceb> ok that looks ok then
[19:51] <hallam> because of the geometry, both noise and systematic error from each sat are amplified along different axes
[19:51] <Laurenceb> its not the dll
[19:52] <hallam> Laurenceb, I'm not so sure
[19:52] <Laurenceb> hmmm
[19:52] <hallam> so there's the line that it's mostly spread along, right?
[19:52] <Laurenceb> yeah
[19:52] <hallam> there's systematic error along that line and also noise
[19:52] <hallam> both are stretched along that line
[19:52] <Laurenceb> yeah
[19:52] <edmoore> fwiw, this plot shows the correlation (in the statistical sense) a little better http://img232.imageshack.us/img232/7033/gpssatin1.jpg
[19:52] <hallam> in the perpendicular direction there's also systematic error and noise, but smaller
[19:52] <edmoore> that henry is refering to
[19:53] <Laurenceb> hmm
[19:53] <Laurenceb> yeah
[19:53] <fergusnoble> the line almost goes through the correct point if that makes any difference
[19:53] <edmoore> it's certainly helpful that it does
[19:53] <Laurenceb> theres certainly too muc h noise
[19:53] <fergusnoble> edmoore: can yo plot that graph with the correct point on it too
[19:54] <edmoore> what's the correct point?
[19:54] <Laurenceb> hallam: are you correcting the pseudoranges with the dll?
[19:54] <edmoore> just give me the number and i'll put it on
[19:54] <Laurenceb> 52 12' 7.4981'' N 0 7' 5.4272'' E
[19:54] <edmoore> numbers*
[19:54] <fergusnoble> it certainly highlights the stratification
[19:54] <hallam> Laurenceb: the DLL directly affects the code phase that's recorded with each ms
[19:54] <edmoore> in decimal :p
[19:54] <hallam> yeah seriously laurence, what's with the deg min sec
[19:55] <Laurenceb> 52 12/60' 7.4981/3600'' N 0 7/60' 5.4272/3600'' E
[19:55] <edmoore> can someone other than laurence give me the point at which the data was taken?
[19:55] <Laurenceb> its the output from plotresults
[19:55] <hallam> fergusnoble: do you understand what I mean about how both sorts of error get amplified by the geometry?
[19:55] <fergusnoble> hallam: yes, i think so
[19:55] <Laurenceb> 52.20208281N
[19:56] <Laurenceb> 0.1181742222E
[19:56] <hallam> so I think if we smooth them somehow it'll sort out the nav
[19:56] <fergusnoble> Laurenceb: that pust be down to the millimeter :)
[19:56] <hallam> Laurenceb: the reason I think it must be something in the tracking loop is that even getting pseudoranges from absolute sample time like borres shows the same trend, just with more quant noise
[19:57] <Laurenceb> hallam: sorry to go over this, but I dont see where the earths rotation is corrected for
[19:57] <Laurenceb> hallam: yesh I follow you
[19:57] <hallam> I'll try and find it, I'm sure I saw it in the code
[19:57] <Laurenceb> I've just gone through
[19:57] <Laurenceb> cant see it
[19:57] <fergusnoble> Laurenceb: its all done in a coord frame that rotates with the earth
[19:57] <Laurenceb> its ~25m
[19:57] <Laurenceb> sure
[19:58] <Laurenceb> but the sats arent in that frame
[19:58] <Laurenceb> oh crap
[19:58] <fergusnoble> Laurenceb: so i think in effect its corrected by the data about where the sats are
[19:58] <Laurenceb> argggg einstien
[19:58] <Laurenceb> damn you
[19:58] <Laurenceb> yeah I think it doesnt matter
[19:58] <hallam> leastsquarepos.m line 60
[19:59] <hallam> albeit with somewhat poor grammar
[19:59] <hallam> I would also like to find the elevation angel of the satellite
[19:59] <Laurenceb> ah ok
[19:59] <Laurenceb> thanks
[19:59] <Laurenceb> yeah I was just thinking you could ignore the facxt its rotating
[19:59] <hallam> http://satellite.ytmnd.com/
[19:59] <Laurenceb> but that wouldnt work as its a non inertial frame
[20:00] <fergusnoble> hallam: could you take one position and then plot what happens when you vary the first sat's psudorange?
[20:00] <Laurenceb> ok, all makes sense now :P
[20:00] <hallam> fergusnoble: ok, hang on
[20:00] <Laurenceb> it wont matter
[20:00] <hallam> none of you are allowed to turn that off until we solve it
[20:01] <Laurenceb> you guesstimate the first sats prsudorange
[20:01] <Laurenceb> arg audio off audio off
[20:02] <edmoore> i think the data set in my matlab file is truncated compared to hallams
[20:02] <edmoore> sorry
[20:02] <Laurenceb> you guesstimate the first stas speudorange, then the solver takes care of the rest
[20:02] <hallam> you should have 600 points IIRC
[20:03] <hallam> edmoore: I just don't think there's any interesting information in that data
[20:03] <edmoore> sure no probs, got the correlation off
[20:03] <edmoore> i was interested in the analysis of the parallel lines of data
[20:03] <hallam> that's just sat geometry
[20:03] <hallam> I mean sure, it's cool
[20:06] <hallam> http://uploads.mibbit.com/up/IfodCdpg.png
[20:06] <hallam> so
[20:06] <hallam> true position is as before
[20:06] <hallam> black star is the original solution
[20:06] <hallam> blue dots are the solutions with each sat in turn having its pseudorange adjusted by 0.25 chips
[20:07] <hallam> I forget which one is which sat, but that doesn't really matter
[20:07] <fergusnoble> hallam: a few more points would be nice if thats easy to do?
[20:07] <hallam> they'll just be straight lines through those ones
[20:07] <hallam> yeah I just checked, they are
[20:07] <fergusnoble> oh i see, sorry i thought they were all from changing the same sat
[20:08] <hallam> no, different sats
[20:08] <hallam> so you can see that the two largest vectors correspond to the two directions the data is noisiest in
[20:09] <hallam> I'm pretty sure now that it's a DLL issue
[20:09] <fergusnoble> ok, so its not clearly any one sat thats wrong, which is good
[20:09] <Laurenceb> whats red and green?
[20:10] <hallam> red = your fix, green = my very quick guesstimate from google maps
[20:10] <hallam> your fix is probably better
[20:10] <fergusnoble> hallam: you notice two sats go in almost the same direction?
[20:10] <hallam> yeah, presumably because they're in similar parts of the sky
[20:10] <fergusnoble> hallam: could that mean that you have only 3 degrees of freedom
[20:10] <hallam> we haven't plotted altitude
[20:10] <fergusnoble> and so with 4 sats you cant solve it so easily
[20:11] <hallam> no, there are exactly 4 DOF
[20:11] <hallam> X,Y,Z, time
[20:11] <fergusnoble> true, the alitude would be different
[20:11] <fergusnoble> hallam: but if you have a degeneracy in your information
[20:11] <hallam> oh totally
[20:11] <hallam> that's pretty much what the various DOP are
[20:11] <hallam> a measure of that degeneracy
[20:11] <Laurenceb> http://www.b3tards.com/u/d81a83cf6d5a93144ba7/bus_stop_bigger.jpg
[20:12] <fergusnoble> i mean, you have 4 DOF in your fix, but only 3 and a bit DOF in your data
[20:12] <hallam> but
[20:12] <hallam> yeah
[20:12] <hallam> but
[20:12] <hallam> that should end up meaning it's noiser in some directions than others
[20:12] <hallam> which is fine
[20:12] <fergusnoble> yeah, ok, that makes sense
[20:12] <hallam> but the centroid of the fixes should still be on top of me
[20:12] <hallam> or within 10m or so (ionosphere and stuff that we haven't corrected for)
[20:12] <Laurenceb> hallam: my data fors an ellipse
[20:13] <fergusnoble> and i guess the data is ok because that what Laurenceb used
[20:13] <hallam> yeah
[20:13] <hallam> so I do think it's the code tracking
[20:13] <Laurenceb> I've tried to remove the pseudorange quantisation
[20:13] <hallam> I'm going to try playing with the DLL gain, but not too sure that alone will be enough
[20:14] <Laurenceb> but theres still a bit, as I didint invert the disc function correctly, but its basically an ellipse
[20:15] <edmoore> Laurenceb: would you be able to plot your ellipse for comparison?
[20:15] <fergusnoble> hallam: i have an idea, couldnt it simply be due to only using one subchip resolution?
[20:16] <fergusnoble> together with your observation about the stretching along the lines of solution of the different sats
[20:16] <Laurenceb> I logged out without saving ti sorry
[20:16] <Laurenceb> about 40m radius
[20:16] <Laurenceb> 10m thick
[20:17] <Laurenceb> at a weird angle, axis kind of pointing up at 30 drgrees towards the south south-east
[20:17] <edmoore> the first thing I thought when I saw that scatter was how much it looked like my descent simulation plots when they had quantisation error, I must say.
[20:17] <hallam> ok this is a lot better, but not perfect yet
[20:18] <hallam> fergusnoble: we have better than one subchip resolution
[20:18] <Laurenceb> theres cartainly quantisation in there
[20:18] <hallam> http://uploads.mibbit.com/up/GnkfvjYv.png
[20:18] <hallam> this was just from reducing the DLL gain
[20:18] <edmoore> wow
[20:19] <hallam> just going to see how much abs error that is
[20:19] <Laurenceb> hmm
[20:23] <hallam> still 90m abs error but much less noise
[20:23] <Laurenceb> yeah
[20:23] <Laurenceb> are you using DLL disc output to improve resolution?
[20:24] <fergusnoble> hallam: the mean position is still the same?
[20:24] <hallam> Laurenceb: yes
[20:24] <Laurenceb> hallam: sure your using the right sign ect?
[20:24] <hallam> fergusnoble: no, closer than it was, but still 90m out (instead of about 120)
[20:25] <hallam> Laurenceb: it's done automatically in the DLL, if it was wrong it would all be wrong
[20:25] <edmoore> hallam, from a histogrammy perspective, is the lock desnsity higher nearer the mean?
[20:25] <Laurenceb> right
[20:25] <edmoore> or is it pretty uniform?
[20:26] <edmoore> could help ascertain the kind of noise it's being subject to
[20:29] <hallam> edmoore: don't know, would guess not, remind me later to actually check
[20:29] <edmoore> willdo
[20:29] <hallam> but there's always going to be phase noise
[20:29] <hallam> got it down to 40m error just by adjusting DLL gain
[20:29] <hallam> I think if I make the DLL 2nd-order it will be a lot better
[20:29] <edmoore> made some 3d histogram routines for myself for analysing stuff over the summer, if you want me to check. but it's only a couple of mins of script
[20:29] <Laurenceb> but its already carrier aided?
[20:30] <hallam> yeah, can keep that
[20:30] <hallam> or otherwise I can post-smooth the data
[20:33] <hallam> down to about 25m
[20:33] <hallam> I think more than this will need post-smoothing
[20:34] <Laurenceb> 25m overall error?
[20:35] <hallam> yeah
[20:36] <Laurenceb> hey not bad
[20:36] <Laurenceb> what did you do?
[20:37] <hallam> just decreased DLL gain
[20:37] <hallam> hmmm now if I normalise the DLL gain by the signal strength
[20:38] <Laurenceb> I though you said before that you had the error in pseudorange down to 6m
[20:38] <edmoore> 'you have twelve balls, all of equal mass, except one, which can be either slightly heavier or slightly lighter. You also have a pair of balancing scales, which can be used to see which pan's contents is the heavier. Each pan can hold up to six balls. Find and prove the optimal strategy for finding which ball is of a different mass, using as few weighings as possible'.
[20:38] <edmoore> sometimes you just want to stab an examples paper in the face
[20:39] <fergusnoble> its a good question
[20:39] <fergusnoble> proving optimal algorithms is an interesting problem
[20:39] <edmoore> it's lovely I'm sure. Just need to find the answer
[20:39] <Laurenceb> in an exam that would suck
[20:40] <edmoore> it is a past tripos q
[20:40] <Laurenceb> getting stressed in exams is not good
[20:40] <edmoore> it's sort of unrelated to our courses though, just given as interest rather than testing anything specific
[20:41] <edmoore> I think I see a way in
[20:41] <edmoore> we can first decide whether to do 6 v 6, 5 v 5, 4 v 4, 3 v 3 etc on the scales
[20:42] <fergusnoble> what does the balance do if you if the two pans are the same?
[20:42] <edmoore> it balances
[20:42] <edmoore> in the middle
[20:42] <fergusnoble> ok, so you know that
[20:42] <edmoore> yep
[20:42] <edmoore> so i think i see how to do this anyway
[20:42] <hallam> 6m of pseudrorange -> much more of position, due to the DOP
[20:42] <Laurenceb> true
[20:42] <edmoore> 6v6/5v5/4v4 etc is easy enough to find the optimal one entropically
[20:43] <fergusnoble> edmoore: can do it in 12 weighings
[20:43] <edmoore> my doodlings reckon 3
[20:43] <fergusnoble> maximum
[20:43] <edmoore> i just need to develop this
[20:43] <fergusnoble> ok
[20:43] rjharrison_ (n=rharriso@80.176.172.227) joined #highaltitude.
[20:43] <edmoore> 4v4 is the optimum strategy from an information theory pov i think
[20:44] <edmoore> I know*
[20:45] <edmoore> then you can do divide and conquer in 3 steps
[20:45] <edmoore> but that's a bit of a minging CS student answer.
[20:45] <fergusnoble> how do you know how to divide?
[20:46] <edmoore> oh, it may be that you can tackle this from a state space POV
[20:46] <edmoore> define all possible states in the ensemble
[20:46] <edmoore> ok got it
[20:47] <edmoore> fergusnoble: if you want to divide and conquor, you would first do a weight with 4 vs 4 and either have a 'heavy' batch or a 'light' batch
[20:47] rjharrison (n=rharriso@80.176.172.227) left irc: Read error: 110 (Connection timed out)
[20:47] <edmoore> or 'both equal'
[20:47] <edmoore> for 'both equal' you know the squiffy ball is in the remaining 4, not the 8 you just tested
[20:48] <edmoore> all the other solutions are derivative
[20:48] <edmoore> but in state-space you can do it with, i think, 3 tests of 4 x 4. provably
[20:49] <hallam> there are 24 possible states, right?
[20:49] <edmoore> 27 by my maths
[20:50] <hallam> 12 possible balls, then whether it's lighter or heavier
[20:50] <hallam> or is that a bit naive
[20:50] <edmoore> for the state approach anyway. I *think* this works in which case I'm pleased as I just looked at the solution and it was divide and conquer, but this is cooler
[20:50] <edmoore> so consider the set of possible outcomes from a test
[20:51] <edmoore> X (left side lighter), Y (left side heavier), Z (balanced)
[20:51] <edmoore> oh hang on...
[20:51] <edmoore> oh no wait, this does work
[20:52] <edmoore> yep sorry
[20:52] <edmoore> so you have 3 possible outcomes
[20:53] <hallam> Ideally you'd have 2.89 weighings
[20:53] <edmoore> this is starting from the assumption that 4 v 4 is optimal, which it is by shannon's information theory
[20:53] <hallam> suggesting that less than three is rather tricky
[20:53] gregHome (n=gleblanc@75.108.33.75) left irc: "ChatZilla 0.9.84 [Firefox 3.0.5/2008120122]"
[20:53] rjharrison_ (n=rharriso@80.176.172.227) left irc:
[20:53] <hallam> log(12*2)/log(3)
[20:53] <edmoore> but consider it in a state-space way. each kind of ball can be on the left side, on the right side, or off the scales
[20:54] <edmoore> you need to devise a weighing scheme such that in 3 tests, all balls are on the scales exactly twice, and no two ever share the same pan more than once
[20:54] <edmoore> so you name your balls based on the base-3 state (just bear with me)
[20:56] <edmoore> XXY XYX XYY XYZ YYZ YZX YZY YZZ ZXX ZXY ZXZ ZZX
[20:57] <edmoore> I have rejected repeated ones (eg XXX) and ones that are just the reverse of a previous one
[20:57] <hallam> that's certainly how I name my balls
[20:57] <fergusnoble> edmoore: you can deffo do it in 3 with div and conq, just proved it
[20:57] <edmoore> sure that's easy
[20:58] <edmoore> that's the 20 mins exam question. this is funner though :D
[20:58] <edmoore> so the first test looks like this:
[20:59] <edmoore> XXY XYX XYY XYZ | YYZ YZX YZY YZZ
[20:59] <edmoore> XXY ZXX ZXY ZXZ | XYX XYY XYZ YYZ
[21:00] <edmoore> XYX YZX ZXX ZZX | XXY XYY YZY ZXY
[21:00] <edmoore> ok, those are the three tests
[21:01] <edmoore> all balls get 2 tests, no pair of balls ever are in the same pan as one another more than once
[21:01] <edmoore> now remember the code: X = left heavy, Y = right heavy, Z = ballanced
[21:01] <edmoore> say ball XYZ is heavier than the others
[21:02] <edmoore> in the first test, it is on the left pan, making left heavey, making 'X' the result
[21:02] <edmoore> in the second test, it is in the right pan, making the right heavy, making 'Y' the result
[21:03] <edmoore> in the 3rd test, it is not on the scales, meaning they will be balanced, making 'Z' the result
[21:03] <edmoore> In order: 'X', 'Y', 'Z'
[21:03] <edmoore> in other words, a state-space model actually spells out the name of the squiffy ball
[21:03] <edmoore> oh my lord, god is beautiful
[21:04] <edmoore> maths is definitely discovered
[21:05] <fergusnoble> edmoore: thats nice
[21:05] <hallam> that's quite pretty
[21:06] <hallam> I really love how the tracking is the step that takes the least time of the whole program
[21:06] <fergusnoble> but it is exactly the same as the div and conq proof only a different notation
[21:06] <edmoore> that's made me want a beer. I'm not sure i'd have got the all down in the exam time though
[21:07] <edmoore> well it proves the same result, but the way it goes about it is different
[21:07] <fergusnoble> i think the proof trajectory is the same?
[21:07] <fergusnoble> actually its identical
[21:08] <fergusnoble> but it is a very elegant exposition
[21:09] <fergusnoble> although actually, there is a small difference in how you construct your sets to test
[21:10] <edmoore> yes, that's what i'm trying to form my thoughts on to answer you
[21:10] <edmoore> but i'm not sure my mtahs is formally good enough to discuss proof trajectories :)
[21:11] <fergusnoble> ive got a sketch proof in set theoretical notation which shows how they are almost the same
[21:11] <edmoore> I basically went in reverse - from the 27 possible ball trajectories to the 24 possible outcomes
[21:12] <edmoore> and then the 12 outcome vecotors
[21:13] <edmoore> it's non-branching unlike DaConq, but I'm not sure of the significance of that.
[21:14] <fergusnoble> descovery at each stage of x,y or z can be seen as a branch in the possible outcomes
[21:14] <edmoore> actually sure, qualitatively the analog is that with each weigh we partition the set of possible states
[21:17] <fergusnoble> if you define a set of balls {a, b...b} i.e. 11 b's and a is the odd ball
[21:18] <fergusnoble> you can make a function which partitions a set like that into three, counts the b's in two of the partitons and returns the uncounted set if they are equal or the union of the two counted sets if unequal and then recureses
[21:19] <edmoore> so the true state (odd ball) can be learned in n experiments without braching iff you can find n partitions whose intersection is the partition by singletons - assuming I've got my set theory terminology right
[21:19] <fergusnoble> i think you can show for a sensible choice of partiton that for 12 balls you only need to recurse 3 times max
[21:19] <edmoore> i use iff deliberately ^
[21:19] <edmoore> does that make sense?
[21:20] <edmoore> yes, that's the word i wanted
[21:21] <fergusnoble> edmoore: yeah, sounds right, you get the empty set for some of your intersections, but you can find the partitons where the intersections contain at most one element
[21:21] <hallam> http://uploads.mibbit.com/up/StNWssgI.rar <-- movie of the position drift over time
[21:21] <hallam> width of the frame is about 55m, it's over 30 seconds
[21:21] <edmoore> fergusnoble: fazackerly
[21:22] <edmoore> cool
[21:22] <edmoore> well I hope i'd get the marks for that
[21:22] <edmoore> I think the nub of the question was probably realising that 4v4 was the best method
[21:22] <edmoore> though the crib doesn't prove that....
[21:22] <edmoore> next-to-useless
[21:22] <hallam> well
[21:22] <hallam> most of that was over my head
[21:23] <hallam> but am I right in thinking that log(12*2) / log(3) > 2 proves that you can't do it in less than 3 weighings?
[21:23] <hallam> therefore you just have to find one method that works with 3, and it's optimal
[21:24] <fergusnoble> hallam: that sounds good too
[21:24] <fergusnoble> hallam: also highlights the fact that most of the time you will do it in less than three
[21:24] <fergusnoble> sorry, not most of the time
[21:24] <fergusnoble> but often
[21:24] <hallam> some of the time
[21:25] <edmoore> are you sure about that?
[21:26] <hallam> I think it means that you could design a method that on average gave it to you in 2.89 weighings
[21:26] <hallam> or maybe, the inverse
[21:27] <hallam> you can't design a method that will give it to on average in less than 2.89 weighings
[21:27] <hallam> fairly confident about that
[21:28] <fergusnoble> actually, i think you always need three, because if you know the odd ball is one of only two balls you cant weigh them to determing which it is
[21:28] <edmoore> i guess if you do some 1 v 1s and get lucky
[21:29] <edmoore> X is heavy. X vs Y, X wins. X vs Z, X wins. Therefore X is squiffy. 2 moves
[21:30] <hallam> quite lucky
[21:30] <fergusnoble> yeah, but thats not using an algorithm which is also optimal
[21:30] <hallam> hm
[21:30] <edmoore> no ideed, that's why i questioned the assertion
[21:30] <hallam> actually the method ed just described will tell you if it is X or Y
[21:30] Simon-MPFH (n=simon@phantom.mpfh.co.uk) left irc: "Leaving"
[21:30] <hallam> and if it's neither, you can pick another one to weigh against either of X and Y
[21:30] Xenion (n=robert@p579FC8B1.dip.t-dialin.net) joined #highaltitude.
[21:31] <edmoore> I think if the results turned out as i diescribed, it's definitely X
[21:31] <hallam> yeah
[21:31] <hallam> but if it were Y instead, you'd still know
[21:31] <edmoore> sure yes
[21:31] <hallam> therefore in 2 tests, you get 3 chances to identify a ball
[21:31] <fergusnoble> but imagine if the squiffyness was that the ball was lighter
[21:31] <hallam> so it's not as bad as having to be 1 in 12 lucky, only 1 in 4 lucky
[21:32] <fergusnoble> the point is you dont know if its light of heavy
[21:32] <hallam> well you find that out in the 2nd weighing, don't you
[21:32] <hallam> X is light. X vs Y, Y wins. Y vs Z, equal therefore X squiffy
[21:32] <edmoore> yes - if in my example Y was light, you'd find that out too
[21:32] <fergusnoble> but you can still do it in two like this X vs Y give unequal then Y vs Z gives the same then you know its X
[21:32] <hallam> righ
[21:33] <edmoore> we've all just said the same thing
[21:33] <hallam> :)
[21:33] <hallam> time for some nav code in C
[21:33] <hallam> or acq
[21:33] <hallam> Nav or acq?
[21:33] <edmoore> time for next question
[21:33] <fergusnoble> hallam: giving up on this error then?
[21:33] <hallam> for now, I've got it pretty small
[21:33] <hallam> it's now comparable to the noise
[21:34] <fergusnoble> edmoore: me and henry said the same thing, you said something different i think
[21:34] <hallam> I think he said the same thing
[21:34] <fergusnoble> hallam: ok cool, i'd like to see the nav code in C :)
[21:34] <edmoore> i think i did. i may have had different outcomes but that's arbitrary
[21:34] <hallam> okay, nav it is
[21:35] <hallam> here's an interesting one though
[21:35] <fergusnoble> edmoore: oh my mistake, i didnt read you correctly
[21:35] <hallam> if you don't care about finding out whether it's heavy or light, just that it's different
[21:35] <edmoore> np
[21:35] <hallam> can you do it in fewer than 2 ever? fewer than 3 on average?
[21:35] <edmoore> you can't do it in fewer than 2
[21:35] <edmoore> ever
[21:36] <edmoore> you've have to constrain the problem
[21:36] <fergusnoble> hallam: i thought thats what the question was?
[21:36] <edmoore> to just heavy or just light
[21:36] <hallam> yeah
[21:37] <edmoore> right, might go and get an orange juice
[21:37] <edmoore> have felt horrendous the last 2 days
[21:37] <edmoore> can coffee give you migraines?
[21:54] <fergusnoble> yeah
[21:55] <edmoore> i hope it's not that
[21:55] <edmoore> it's been thumping for the last 36 hrs though
[21:55] <fergusnoble> if you havnt been drinking coffee for that time then i doubt its that
[21:55] <fergusnoble> ask jcoxon
[21:55] <edmoore> i have been
[21:56] <edmoore> but yes, willdo
[22:10] <Laurenceb> god the audio on here
[22:10] <Laurenceb> I've been trying to get the radio working on the min rogallo
[22:10] <Laurenceb> I suspect its the audio on this laptop
[22:11] <Laurenceb> but it doesnt explain why I just couldnt get any data at all after about 5 minute
[22:11] <Laurenceb> is there any way that using fldigi could have caused the soundcard to warm up?
[22:12] <Laurenceb> s/soundcard/crappy sound ic
[22:12] <Laurenceb> I was coping entire packets when it was first turned on
[22:12] <Laurenceb> then the middle broke up, then I had two breakups ect
[22:13] <Laurenceb> obviousl a timing glitch
[22:14] <Laurenceb> its odd that i could fix it by trying to recalibrate the sound
[22:14] <Laurenceb> like the was a jitter on it or something
[22:19] RocketBoy (n=Steve@217.47.75.27) joined #highaltitude.
[22:29] <Laurenceb> hi Steve
[22:29] <Laurenceb> I cant get this radio working still
[22:30] <Laurenceb> do you think it could be the sound on my laptop?
[22:30] <Laurenceb> - causing timing glitches
[22:30] <Laurenceb> bbl sorry
[22:50] <fergusnoble> if you have a set of orthogonal vectors is it possible to find one vector that dotted with any vector in the set gives one?
[22:51] <hallam> Hi chaps
[22:51] <hallam> fergusnoble: intuition says no
[22:51] <hallam> but my linear algebra is crap
[22:51] <hallam> well
[22:52] <hallam> actually
[22:52] <hallam> yes
[22:52] <fergusnoble> ... without constraining the magnitudes of the orth vectors
[22:52] bfirsh (n=ben@host-137-205-75-156.res.warwick.ac.uk) joined #highaltitude.
[22:52] <hallam> yeah
[22:52] <hallam> er
[22:52] <hallam> well it works for i,j,k
[22:52] <hallam> so by symmetry it works for everything else
[22:52] <fergusnoble> 3d is good enough for me
[22:53] Action: hallam waves hands
[22:53] <fergusnoble> oh, right, you mean it works for the set of 3 orthonormal vectors
[22:53] <hallam> can you just use the sum of the three orthogonal vectors, each divided by its magnitude squared?
[22:54] <fergusnoble> yup, that works
[22:54] <fergusnoble> genius
[22:54] <hallam> I don't know if it works every time but I think it does
[22:55] <fergusnoble> yeah, it does, dot product is distributive
[22:55] <hallam> do you know what an invariant set is?
[22:55] <hallam> or invariant space or whatever
[22:56] <fergusnoble> dont think so
[22:56] <hallam> ok
[22:56] <hallam> man I wish Tova would still talk to me, she could explain this stuff
[23:07] RocketBoy (n=Steve@217.47.75.27) left irc: "Leaving"
[23:14] <edmoore> hallam: observe
[23:15] <edmoore> rocked my world
[23:15] <edmoore> though i've not been through the whole thing
[23:16] <edmoore> but if you want a good intuition, that's the one
[23:16] <edmoore> (free)
[23:30] edmoore (n=edmoore@pomegranate.chu.cam.ac.uk) left irc:
[23:51] <Laurenceb> arg rocketboy has gone
[23:51] <Laurenceb> wanted to ask him about radio
[23:55] <Laurenceb> hallam: hows it going?
[23:57] <Laurenceb> bfirsh: hows warwick?
[00:00] --- Thu Jan 29 2009