highaltitude.log.20090130

[00:32] hallam (i=836fc8c8@gateway/web/ajax/mibbit.com/x-5f03f2cce7112c38) joined #highaltitude.
[02:50] josepharmbruster (n=josephar@45.144.119.70.cfl.res.rr.com) joined #highaltitude.
[03:54] josepharmbruster (n=josephar@45.144.119.70.cfl.res.rr.com) left irc: Read error: 113 (No route to host)
[05:18] hallam (i=836fc8c8@gateway/web/ajax/mibbit.com/x-5f03f2cce7112c38) left irc: "http://www.mibbit.com ajax IRC Client"
[06:12] Simon-MPFH (n=simon@phantom.mpfh.co.uk) joined #highaltitude.
[06:29] EI5GTB (n=Paul@apollo.paulsnet.org) left irc: Read error: 104 (Connection reset by peer)
[07:01] Simon-MPFH (n=simon@phantom.mpfh.co.uk) left irc: "Leaving"
[07:34] natrium42 (i=natrium4@CPE000625d867e2-CM0014045885be.cpe.net.cable.rogers.com) left irc:
[07:59] edmoore (n=edmoore@pomegranate.chu.cam.ac.uk) joined #highaltitude.
[08:07] edmoore (n=edmoore@pomegranate.chu.cam.ac.uk) left #highaltitude.
[08:12] Laurenceb (n=laurence@dyres221-140.surrey.ac.uk) left irc: Remote closed the connection
[08:45] Hiena (n=Hiena@81.93.195.181.datatrans.hu) joined #highaltitude.
[08:52] Laurenceb (i=83e34f19@gateway/web/ajax/mibbit.com/x-e4cfc682fd9d0846) joined #highaltitude.
[08:52] <Laurenceb> hello
[09:07] rjharrison_quiet (n=rharriso@gateway.hgf.com) joined #highaltitude.
[09:07] <rjharrison_quiet> fergusnoble: Is CUSF thinking aboout a launch this w/e?
[09:11] rjharrison (n=rharriso@80.176.172.227) left irc:
[09:12] Nick change: rjharrison_quiet -> rhjharrison
[09:12] <rhjharrison> .
[09:12] Nick change: rhjharrison -> rjharrison
[09:12] <rjharrison> .
[09:12] <rjharrison> that's better
[10:10] <rjharrison> FYI The ISS should be listenable today at 13:13 on 145.800
[10:10] <Laurenceb> pity I dont have any antennas
[10:11] <rjharrison> Oh dear, not even a wire coat hanger?
[10:11] <Laurenceb> :P
[10:17] <Hiena> Hehehehehe...
[10:18] <Hiena> Not even a paperclip?
[10:33] <Laurenceb> I'm trying to get ionospheric correction working on henrys data
[10:34] <Laurenceb> which is tricy as you need page 18 of subframe 4
[10:34] <Laurenceb> so I've just fudged it using a priori data
[10:35] Xenion (n=robert@p579FC067.dip.t-dialin.net) left irc: Read error: 101 (Network is unreachable)
[10:35] Xenion (n=robert@p579FCE53.dip.t-dialin.net) joined #highaltitude.
[10:37] jcoxon (n=jcoxon@host86-158-31-172.range86-158.btcentralplus.com) joined #highaltitude.
[10:40] rjharrison (n=rharriso@gateway.hgf.com) left irc:
[10:46] <jcoxon> morning all
[10:57] <jcoxon> fergusnoble, ping
[11:10] borism (n=boris@195-50-211-134-dsl.krw.estpak.ee) joined #highaltitude.
[11:13] <Laurenceb> http://www.moonrakerukltd.com/Amateur-Radio/Beam-Antennas/ZL-Special/ZL7-70
[11:14] <Laurenceb> ^ anyone got one of those?
[11:14] borism_ (n=boris@195-50-211-166-dsl.krw.estpak.ee) left irc: Read error: 145 (Connection timed out)
[11:34] <Laurenceb> how do you connect to that?
[11:35] <Laurenceb> the coax is swrewed in?
[11:39] <jcoxon> probably its a BNC connector
[11:40] <jcoxon> i think its the yagi that rocketboy has
[11:44] <Laurenceb> yeah#
[11:44] <Laurenceb> I have a bnc to connect to the icom
[11:45] <Laurenceb> IIRC his has the coax screwed it
[11:50] <jcoxon> as in has a cable already attached?
[11:53] <Laurenceb> I though there was omse sort of clamp arrangem,ent inside the black justion box type thingy
[11:53] <jcoxon> i think there is a cable
[11:54] <Laurenceb> arg my typing
[11:54] <Laurenceb> sure, theres an RG58
[11:54] <Laurenceb> but I thought it was clamped in place or something at the antenna end
[11:57] rjharrison (n=rharriso@gateway.hgf.com) joined #highaltitude.
[11:57] <jcoxon> Laurenceb, oh i don't know
[11:57] <rjharrison> fergusnoble: Ping
[11:57] <rjharrison> Hi jcoxon
[11:57] <rjharrison> Any news on CUSF launch tomorrow>
[11:58] <rjharrison> ?
[11:58] <rjharrison> There was some chatter late last night
[11:58] <SpeedEvil> :/
[11:58] <jcoxon> oh a launch?
[11:58] <jcoxon> i heard a few hints earlier this week
[11:58] <rjharrison> Thought we might get the listener in action
[11:58] <jcoxon> yesterday was tres busy
[11:58] <rjharrison> hehe
[11:58] <SpeedEvil> I've thought up a really, really clever parallel search algorithm.
[11:58] <rjharrison> Play or work
[11:59] <jcoxon> rjharrison, both
[11:59] <jcoxon> A+E all day and then theatre
[11:59] <SpeedEvil> :/ as it's possibly too clever to reveal in public channels.
[11:59] <rjharrison> We need to twist a CUSF to get the early data in
[11:59] <rjharrison> CUSF arm even
[12:00] <jcoxon> early data in?
[12:00] <rjharrison> Perhaps ed could run the python script on his eee
[12:00] <rjharrison> The first 6km
[12:00] <jcoxon> oh right
[12:00] <jcoxon> ummm yeah
[12:01] <jcoxon> the bad news is that i've managed to break my auto tuner
[12:01] <Laurenceb> SpeedEvil: go on then
[12:01] <jcoxon> and my cable for the ft-817 hasn't arrived
[12:01] <rjharrison> We / I can do the next 80% before final descent
[12:01] Ebola (i=ebola@unaffiliated/ebola) left irc: Remote closed the connection
[12:01] <rjharrison> Which cable
[12:01] <rjharrison> antenna?
[12:01] <SpeedEvil> And anyway, I need to code it to see if it works as I think it should.
[12:02] <jcoxon> rjharrison, no the data cable for hamlib
[12:02] <Laurenceb> maybe I could do a groundstation
[12:02] <rjharrison> Sorry SpeedEvil: Will chat in a bit
[12:02] <Laurenceb> need an antenna
[12:02] <jcoxon> Laurenceb, make a moxon
[12:02] <Laurenceb> I plan to make a power supply for the iconm
[12:02] <rjharrison> You not around sat?
[12:02] <jcoxon> while they have debatable radiation you can make useful antenna out of coathangers
[12:03] <jcoxon> rjharrison, i will be
[12:03] <Laurenceb> hmmm
[12:03] <jcoxon> i'll hand tune
[12:03] <jcoxon> Laurenceb, its what i use
[12:03] <Laurenceb> I'm not sure of the best place to get an ant
[12:03] <Laurenceb> :P
[12:03] <Laurenceb> I'll probably go for moonraker, its the cheapest
[12:04] <Laurenceb> need to save money so I can pay off student loan
[12:04] <jcoxon> Laurenceb, make a moxon and join our listener system for tomorrow's launch
[12:04] <Laurenceb> he
[12:04] <Laurenceb> well for a start I'd need a power supply
[12:04] <Laurenceb> I'm nowhere near ready
[12:05] <jcoxon> don't have a variable supply anywhere?
[12:05] <Laurenceb> need power supply, internet acess, yagi, coax, sonme sort of casde, ideally a tripod....
[12:05] <Laurenceb> yes, but it needs to run off a large lead acid cell
[12:05] <Laurenceb> well not that l;arge
[12:05] <jcoxon> Laurenceb, why are you being mobile?
[12:06] <Laurenceb> it needs to be
[12:06] <jcoxon> not for tracking a launch tomorrow
[12:06] <Laurenceb> theres no chance of receprion anywher enear my room
[12:06] <Laurenceb> I'd have to go about 200m or so to have a good field of view
[12:07] <jcoxon> haha i doubt that if you run a forecast
[12:07] <jcoxon> just did a cusf forecast for today
[12:07] <jcoxon> lands near woking
[12:07] <Laurenceb> hmm
[12:07] <jcoxon> Laurenceb, i receive well in london
[12:07] <jcoxon> with larger buildings around
[12:07] <jcoxon> and i'm indoors with my antenna taped to my window
[12:08] <Laurenceb> what sort of ant?
[12:08] <jcoxon> 70cm moxon
[12:08] <jcoxon> out of coathangers
[12:08] <rjharrison> jcoxon: whats the track looking like for tomorrow?
[12:08] <jcoxon> http://www.moxonantennaproject.com/sm5jab/sm5jab_2.htm
[12:08] <jcoxon> rjharrison, on the case right now
[12:09] <rjharrison> Laurenceb: Just get the coathanger out
[12:09] <rjharrison> That should be fine
[12:09] <Laurenceb> yeah, but I dont have coax or anything
[12:09] <Laurenceb> I cant get all the parts by tomorrow
[12:09] <Laurenceb> grr
[12:10] <SpeedEvil> got any spare TV cables?
[12:10] <jcoxon> go to maplin and get some RG58 cable and bnc connector
[12:10] <Laurenceb> hmm
[12:10] <rjharrison> I'm going to try to tune into the ISS at 13:13 today
[12:10] <rjharrison> 145.800
[12:10] <Laurenceb> yeah I have bnc connector
[12:10] <Laurenceb> that ant looks interesting
[12:10] <Laurenceb> maplin in guildford is pants
[12:11] <Laurenceb> guess I could use tv coax
[12:11] <jcoxon> it'll land 35km from oxford
[12:11] <jcoxon> surely tv coax is bad
[12:12] <Laurenceb> bbl
[12:12] <SpeedEvil> tv coax is just fine
[12:12] <SpeedEvil> 'satellite' coax is better
[12:12] <SpeedEvil> and low loss at 433MHz
[12:12] <SpeedEvil> satellite coax is available even in B+Q
[12:12] <SpeedEvil> or focus
[12:14] <rjharrison> jcoxon: You going to post the track?
[12:17] <jcoxon> ummm yeah one sec
[12:18] <rjharrison> Be cool to test the listener. I have 2E0 @ 1:30
[12:18] <rjharrison> on sat
[12:20] <jcoxon> http://www.pegasushabproject.org.uk/misc/balloon-2.kml
[12:21] <rjharrison> thanks
[12:22] <jcoxon> what time was ISS?
[12:23] <jcoxon> actually no worries
[12:23] <jcoxon> will bbl
[12:23] jcoxon (n=jcoxon@host86-158-31-172.range86-158.btcentralplus.com) left irc: "Leaving"
[12:27] Ebola (i=ebola@unaffiliated/ebola) joined #highaltitude.
[12:33] <Laurenceb> is sat coax solid core?
[12:33] <Laurenceb> itsnt it 75 ohm?
[12:36] <Laurenceb> hmm I have some foam sheets I think
[12:37] <Laurenceb> I'll use some better quality wire - copper
[12:37] <Laurenceb> then glue it to the floam
[12:40] <SpeedEvil> don't you ant solid core?
[12:41] <SpeedEvil> Err
[12:41] <SpeedEvil> I mean 75 ohm
[12:41] <SpeedEvil> Oh - prolly not
[12:41] <SpeedEvil> The other alternative if you've got an old computer bits bin is 10base-2
[12:41] <SpeedEvil> 50r
[12:42] <Laurenceb> no
[12:42] <Laurenceb> whats the impedance of sat coax?
[12:42] <SpeedEvil> 75R
[12:42] <SpeedEvil> I'm pretty sure, same as TV
[12:42] <Laurenceb> ah
[12:42] <Laurenceb> I thought TV was 50
[12:42] <SpeedEvil> nope
[12:44] <Laurenceb> dont think maplin here sell coax
[12:45] <SpeedEvil> they typically have some reels in the back, and it's an ask at the counter thing
[12:45] <Laurenceb> hmm
[12:45] <SpeedEvil> I'd be aastonished if they diddn't have at least some - if only for TV and sat market
[12:46] <Laurenceb> well 50ohm
[12:46] <Laurenceb> hmm guess its worth wandering over there
[12:46] <SpeedEvil> Can always phone and ask
[12:46] <Laurenceb> yeah
[12:46] <SpeedEvil> or I vaguely remember there sis a way to check online stock
[12:46] <SpeedEvil> stock online
[12:46] <SpeedEvil> whis is for what?
[12:46] <SpeedEvil> 433MHz recieve ant?
[12:47] <SpeedEvil> Into a 50R load?
[12:47] <Laurenceb> yes
[12:47] <SpeedEvil> you can always use 75R with a 25R series resistor
[12:48] <SpeedEvil> how much do you need?
[12:48] <Laurenceb> erm
[12:48] <Laurenceb> you mean a blaun
[12:48] <SpeedEvil> Well - no
[12:48] <SpeedEvil> Just a 25R resistor on the centre core.
[12:48] <SpeedEvil> at the reciever end
[12:49] <SpeedEvil> lose 1/3 of the signal amplitude of course
[12:49] <Laurenceb> the ant is 50 ohm
[12:49] <SpeedEvil> Oh - I was assuming you were making your owwon
[12:49] <SpeedEvil> own
[12:50] <Laurenceb> ooh they have RG58
[12:50] <Laurenceb> used the stock checker
[12:50] <Laurenceb> awsomeness
[12:50] <SpeedEvil> :)
[12:51] <Laurenceb> I may pick up some solid core copper as well... check what I've got first
[12:52] <Laurenceb> this should be a good test of my hardware
[12:52] <Laurenceb> I was running some tests last night
[12:52] <Laurenceb> I was copying very well for around an hour
[12:53] <Laurenceb> I think a lot of the problems were due to the amplifude being too high
[12:53] <Laurenceb> my onboard sound was distorting the waveform
[12:58] <Laurenceb> I'm working on adding ionospheric correction to henrys results atm
[12:58] <Laurenceb> annotyingly it seems to be correcting in the wrong direction
[12:59] <rjharrison> ISS in 10 mins
[12:59] rjharrison (n=rharriso@gateway.hgf.com) left #highaltitude.
[12:59] <Laurenceb> ooh
[13:00] rjharrison (n=rharriso@gateway.hgf.com) joined #highaltitude.
[13:00] <Laurenceb> exciting
[13:00] Action: SpeedEvil ponders again.
[13:01] <SpeedEvil> I wonder aT TEH SIZE OF LASERPOINTER THAT'D Be needed to see from ISS caMS IN DAYTIME.
[13:01] <SpeedEvil> Sigh.
[13:01] <SpeedEvil> I need to disable caps lock
[13:04] jcoxon (n=jcoxon@86.158.31.172) joined #highaltitude.
[13:06] <Laurenceb> http://www.mibbit.com/pb/YQeBDx
[13:08] <fergusnoble> jcoxon: hey, whats up?
[13:11] <jcoxon> hey fergusnoble was wondering if you guys were launching this weekend
[13:11] <jcoxon> heard some rumours
[13:12] <fergusnoble> erm, its been talked about, no decision as of yet
[13:12] <jcoxon> oh okay
[13:12] <fergusnoble> we arent in a huge rush to launch if the winds arent good as we dont really have anything exciting to fly
[13:14] <jcoxon> :-)
[13:14] <jcoxon> i ran a forecast for tomorrow
[13:14] <jcoxon> no risk of the sea
[13:15] <jcoxon> goes west
[13:15] <Laurenceb> nice
[13:17] ShellEvil (n=jkffjkjf@tor/regular/SpeedEvil) joined #highaltitude.
[13:17] RocketBoy (n=Steve@217.47.75.27) joined #highaltitude.
[13:18] <Laurenceb> hi RocketBoy
[13:22] <RocketBoy> hiya
[13:23] <RocketBoy> did u sort your radio problem out?
[13:24] <Laurenceb> kind off
[13:25] <Laurenceb> I was testing it last night
[13:25] <Laurenceb> I turned the gain right down
[13:25] <Laurenceb> and it was working a lot better
[13:25] <Laurenceb> think part of the problem is distortion in the soundcard
[13:25] <Laurenceb> but you still have to set a -15000ppm timing offset
[13:26] <Laurenceb> and its glitchy
[13:26] <Laurenceb> I had it running for about an hour, and you could still copy data through fairly reliably
[13:27] <Laurenceb> I was considering writing my own decoder - ideally a transition tracking DLL
[13:27] <Laurenceb> but I'm not sure how to decode pulse shaped code
[13:28] <Laurenceb> surely a PLL is sub optimal
[13:29] <RocketBoy> I would have thought a FFT and somthing to decide if the frequency is hi/lo of a midpoint
[13:29] <Laurenceb> yeah
[13:29] <Laurenceb> but it doesnt respond very well to pulse shaped
[13:29] <ShellEvil> maximal likelyhood?
[13:29] <Laurenceb> maybe downconvert to zero
[13:30] <Laurenceb> then deconvolve with 0-1, 1-0 0-0, 1-1
[13:30] <RocketBoy> you have to find the best fit for transitions to timing methinks
[13:30] <Laurenceb> yes
[13:30] <Laurenceb> hmm
[13:30] <RocketBoy> then sample near midpoints
[13:30] <RocketBoy> thats the way i would do it
[13:31] <Laurenceb> if I have a DLL locked tot he bit positions, then a frequency spoace approach isnt needed
[13:31] <Laurenceb> its quite easy to play with the soundcard under linux... I may play about with some fftw3 code
[13:32] Action: ShellEvil plays Laurencebs theme tune. 'If I had a fft'. (to the tune of If I had a Hammer).
[13:32] <RocketBoy> shame about the 1.5% timing error that seems a lot
[13:33] <RocketBoy> have you tried a different sampling frequency
[13:34] <Laurenceb> yeah
[13:34] <Laurenceb> it doesnt make any difference
[13:34] <RocketBoy> :-(
[13:34] <Laurenceb> but you can see its causing more harmonics
[13:34] <Laurenceb> as its up/down sampling in software
[13:35] <Laurenceb> hmm I'm sure theres a really cool way to do this with some c code
[13:35] <Laurenceb> its good now c supports complex numbers
[13:36] <RocketBoy> does it? its just 2 floats really
[13:37] <Laurenceb> c99
[13:37] <Laurenceb> have you seen the gps ?
[13:37] <Laurenceb> http://imagebin.org/37035
[13:39] <RocketBoy> nope - is that calculated from scratch?
[13:39] <Laurenceb> yes
[13:39] <Laurenceb> using an Se4120
[13:39] <RocketBoy> as in have you replaced the GPS code?
[13:40] <Laurenceb> we used this: http://www.sige.com/uploads/datasheets/SE4120L%20GNSS%20Receiver%20IC%20Datasheet.pdf
[13:40] <Laurenceb> then I processed that result using matlab code
[13:40] <Laurenceb> Henrys working on c code for the blackfin
[13:41] <RocketBoy> cool
[13:42] <jcoxon> hey RocketBoy
[13:44] <Laurenceb> is a PLL an optimal way to decode AFSK?
[13:44] <RocketBoy> I'm no expert but I doubt it these days - perhaps about 1980
[13:47] <RocketBoy> hiya jcoxon
[13:47] <RocketBoy> hows the FT817 (I havn't got one yet)
[13:48] <jcoxon> RocketBoy, i've been really busy so haven't really had a play
[13:48] <RocketBoy> but I have just been paid for some of the FPGA work I have been doing - so a FT817 could be mine shortly
[13:48] <jcoxon> also need a better antenna
[13:50] <RocketBoy> I was thinking of a 33ft vertical 1/4 wave in the back garden
[13:50] <jcoxon> :-p
[13:50] <jcoxon> sadly don't have the space
[13:51] <RocketBoy> Got access to inside the roof sapce?
[13:51] <jcoxon> not really
[13:51] <jcoxon> i'd have to ask i guess
[13:52] <RocketBoy> some form of loop antenna up there might be good
[13:53] <jcoxon> tis a job for another day
[13:54] <RocketBoy> see this http://www.draganfly.com/uav-helicopter/draganflyer-x6/
[13:54] <RocketBoy> I want one
[13:55] <RocketBoy> tis a snip at $15,000
[13:57] <Laurenceb> I want to make a dual roto uav
[13:57] <Hiena> Why not a quadrotor?
[13:57] <Laurenceb> two brsuhless motors
[13:58] <Laurenceb> been done
[13:58] <Hiena> It's a big hype nowdays.
[13:58] <Laurenceb> two brushless motors, counter rotating
[13:58] <Laurenceb> then each one is titlable
[13:58] <Laurenceb> on in roll axis, one in pitch
[13:58] <Hiena> I have a single rotor one in aparts collecting the dust.
[13:59] <Hiena> It's a tail-rotor less design.
[14:00] <RocketBoy> BBL - I have to clean my daughter's car to sell it (I must be doing somthing wrong)
[14:00] <Laurenceb> yeah
[14:00] <Laurenceb> I wanted a design thats easier to build
[14:00] <Laurenceb> hehe
[14:01] <Laurenceb> also, you can embed the rotors oin a foam body
[14:02] <Hiena> Indirect rotor propulsion system is the most symple. No problem with the counterrotating.
[14:02] <Laurenceb> indirect?
[14:02] <Hiena> Yup. One airscrew at the rotor tips.
[14:03] <Laurenceb> like the standard helicoper design?
[14:04] <Laurenceb> thats expensive and easy to damage
[14:05] <rjharrison> hi
[14:06] <Laurenceb> any luck?
[14:06] <rjharrison> ISS :(*
[14:06] <rjharrison> No
[14:06] <Hiena> Nope. It's a tip-jet configuration.
[14:06] <Hiena> Except the brushless motors used instead the jets.
[14:07] <Laurenceb> wut
[14:07] <Laurenceb> this sounds mad
[14:20] <rjharrison> jcoxon: U heard any more on a CUSF launch?
[14:21] <jcoxon> nothing definite
[14:21] <rjharrison> Definte is usually 1 hr b4 launch :)
[14:21] <jcoxon> they haven't made any decisions
[14:21] <rjharrison> We could do with an up date on the tx string
[14:21] <Laurenceb> RocketBoy: could I post you my Tx ?
[14:23] <rjharrison> We don't want that second sentence rubbish again.
[14:23] <jcoxon> hehe
[14:25] <SpeedEvil> hie: hmm. Interesting
[14:25] <Laurenceb> I dont follow
[14:26] <SpeedEvil> Hiena: you trade some of the crapness of ducted fans - their enormous output speed and consequentially poor thrust per watt - using a large rotor as a gearbox.
[14:26] <Laurenceb> I dont follow at all
[14:27] <Laurenceb> ducted fans are more efficient wne moving fast?
[14:27] <SpeedEvil> Laurenceb: assume 100% efficient props and motors
[14:28] <SpeedEvil> Laurenceb: a 10cm prop that needs to produce the same thrust as a 30cm prop needs to move the air 10* as fast.
[14:28] <SpeedEvil> Laurenceb: 10* as fast - mv^2 = 10 times the energy
[14:28] <SpeedEvil> 100
[14:28] <Laurenceb> yeah
[14:28] <Laurenceb> so
[14:29] <SpeedEvil> So, if you use ducted fans for something not moving at a reasonable speed - the system efficiency falls through the floor
[14:29] <Laurenceb> yeah
[14:30] <Laurenceb> this doesnt help
[14:30] <SpeedEvil> A tip-rotor copter though can run at high speeds, allowing you to let the motors scream at 60000RPM and relatively low torque, and the large copter blade acts as a gearbox.
[14:31] <Laurenceb> yeah, but you are still accelerating air from the tips
[14:31] <Laurenceb> to get the torque
[14:31] <Laurenceb> its still a waste of energy relative to two large rotors
[14:31] <SpeedEvil> Sure - but the tip speed of the rotor can be 75% or so of the exhaust speed of the ducted fan jet
[14:31] <SpeedEvil> which moves it into a quite efficient realm.
[14:32] <SpeedEvil> sure.
[14:32] <SpeedEvil> it's a trade, as with everything
[14:32] <Laurenceb> ah, as you are meeting more air
[14:32] <Laurenceb> you dont have to accel it as much
[14:32] <Laurenceb> to get the same thrust
[14:32] <Laurenceb> stationary you have to suck in all your air
[14:33] <Laurenceb> here you get loads shoved in
[14:33] <SpeedEvil> even 'stationary'
[14:33] <Laurenceb> so you just have to accel it a bit to get the same thrust
[14:33] <SpeedEvil> i'd wonder also about silly stuff.
[14:33] <Laurenceb> hmm how would you control this thing...
[14:33] <SpeedEvil> Like being able to rotate one prop blade 180 degrees, and transistion to forward flight
[14:33] <Laurenceb> a three bladed rotor?
[14:34] <Laurenceb> then angle each fan to control attitude
[14:34] <SpeedEvil> A streamlined payload and weight-shift
[14:35] hallam (i=836fc8c8@gateway/web/ajax/mibbit.com/x-23f83ab5654ac713) joined #highaltitude.
[14:35] <Laurenceb> hallam: greets]
[14:35] <hallam> hello
[14:35] <SpeedEvil> swashplate'd be nice, but's complex
[14:35] <Laurenceb> hallam: I've been working on ionospheric
[14:35] <hallam> man, decoding the nav message is a drag
[14:36] <Laurenceb> http://www.navcen.uscg.gov/pubs/gps/sigspec/gpssps1.pdf
[14:36] <hallam> Laurenceb: I took some more data if you want, 5 or 6 sats depending on who you ask
[14:36] <Laurenceb> neat
[14:36] <Laurenceb> could you zip and email it?
[14:36] <Laurenceb> you need to wait up to 12.5minutes for ionosphere
[14:37] <Laurenceb> so I've used some lookup table based on data IO found
[14:37] <Laurenceb> but tis giving incorrect rersuslts
[14:37] <Laurenceb> I think its a problem with clock drift
[14:37] <Laurenceb> if I change the sampling frequency it doesnt effect the fix
[14:37] <Laurenceb> it should
[14:37] <Laurenceb> so I'm working on a clock drift tracker
[14:38] <SpeedEvil> I saw a website with iono corrections online.
[14:38] <SpeedEvil> hmm.
[14:38] <hallam> with this data set you have to tell me the position rather than the other way round
[14:38] <Laurenceb> hehe ok
[14:39] <Laurenceb> I'm going to try and fix the iono first
[14:39] <SpeedEvil> Also I vaguely recall that my neo1973 GPS software spits out a file that is the ephemeris
[14:39] <Laurenceb> hallam: you need page 18 of subframe 4
[14:39] Action: SpeedEvil puts it on charge
[14:39] <Laurenceb> ID=56
[14:39] rjharrison (n=rharriso@gateway.hgf.com) left irc:
[14:40] <Laurenceb> theres 4 s08 parameters
[14:40] <Laurenceb> that pdf explains it
[14:40] <hallam> this is the ionosphere stuff?
[14:40] <Laurenceb> yes
[14:40] <hallam> thanks, but I'm already bored enough just decoding the regular ephemeris
[14:40] <Laurenceb> looking at the error and the sat positions, ionospheric should fix things
[14:40] <Laurenceb> :P
[14:40] <hallam> the parity checking is yaaaawn
[14:41] <Laurenceb> when I worked it out by hand, it was within a meter of the true position
[14:41] <Laurenceb> that sort of stuff is a bit easier in c usually
[14:41] Action: hallam begs to differ
[14:41] <Laurenceb> oh I have a book on pll design
[14:41] <hallam> in c you can't use Borres' code
[14:41] <Laurenceb> unfortunatley high g is quite bad
[14:41] <Laurenceb> yeah
[14:42] <Laurenceb> but high signal strenght makes a big difference
[14:42] <hallam> ok
[14:42] <Laurenceb> you need at least 30 Hz noise bandwidth
[14:42] <hallam> I'll make sure I can reacquire
[14:42] <jcoxon> bbiab
[14:42] jcoxon (n=jcoxon@86.158.31.172) left irc: "Leaving"
[14:44] <Laurenceb> for 10g you need at least 50Hz
[14:45] <hallam> this is with a 1ms filter period?
[14:45] <Laurenceb> I think the combination of carrier aiding and sub one sample pseudorange estimation is the key to making this work really well
[14:45] <Laurenceb> yes
[14:45] <hallam> I should try to figure out how to get my coefficients in terms of nbw and damping
[14:46] <Laurenceb> I've added some code to look at the change in deltatime and adjust the sampling freq variable
[14:47] <Laurenceb> hallam: is there a launch tomorrow?
[14:48] <hallam> there's been talk about one, but I don't think we have a payload ready
[14:48] <Laurenceb> it takes about 10 seconds to get the best fix, but thats due to the very slow time constant in the DLL
[14:48] <Laurenceb> I see
[14:48] <SpeedEvil> 50Hz - for a .01m/s/ms - .05Hz doppler?
[14:48] <SpeedEvil> .05Hz/ms
[14:49] <Laurenceb> that doesnt determine how well it responds todynamics, as the PLL drives the PRN relpica
[14:49] <Laurenceb> yeah
[14:49] <hallam> I'll be back later
[14:49] <hallam> lunch
[14:50] <SpeedEvil> If you're getting noise with around +-6m IIRC with 1ms samples, surely you won't get negative effects on positional accuracy till you're 3m out or so. Which is a 'long' time even at 10g
[14:51] jcoxon (n=jcoxon@host86-158-31-172.range86-158.btcentralplus.com) joined #highaltitude.
[14:51] <Laurenceb> not in terms of the filter response time
[14:51] <SpeedEvil> I think I was assuming a filter that wasn't optimised for position determination.
[14:52] <Laurenceb> noise bandwidth of a pll roughtly corresponds to the frequency it can pull in from
[14:52] <SpeedEvil> just optimised for keeping lock - and the position determining filters run independantly
[14:52] <Laurenceb> yeah
[14:52] <Laurenceb> probably a better way to do it
[14:52] <Laurenceb> then you can kalman filter the results
[14:53] <SpeedEvil> Anyway. /me has to dissasemble a working nice DAB radio, with guarantee.
[14:53] <Laurenceb> what for?
[14:53] <SpeedEvil> I want to jam a mp3 player inside it
[14:54] <SpeedEvil> It's this - http://www.pure.com/products/product.asp?Product=VL-60775
[14:55] <SpeedEvil> which is nice, waterproof, good sound, nice battery life
[14:56] <SpeedEvil> But lacks a mp3 player, so I'm adding one, and a 'dock' port, for easy charging.
[15:08] <Laurenceb> I see
[15:08] <Laurenceb> this is odd... I just cant get it to change the position
[15:08] <Laurenceb> its as if the sampling freqency makes no difference
[15:08] <Laurenceb> but its used to find pseudoranges
[15:09] <Laurenceb> so there should be a % shift in all pseudorange
[15:11] <SpeedEvil> Shouldn't that just come out as a local clock error, and be ignored?
[15:11] <Laurenceb> well local cloock effects all equally
[15:11] fergusnoble (n=fergusno@fn217.quns.cam.ac.uk) got netsplit.
[15:11] <Laurenceb> i.e. its some distance off all pseudoranges
[15:12] <Laurenceb> not a % change in them
[15:14] <Laurenceb> my plan is to find how the delat time in the solution changes for each 1ms solution
[15:15] <Laurenceb> then use it to correct the pseusoranges
[15:15] <Laurenceb> by scaling
[15:15] <Laurenceb> but so far its not working
[15:15] <Laurenceb> annoyingly this code take 30 minutes to run
[15:15] <Laurenceb> need to switch to hallams
[15:16] <Laurenceb> its odd as you increase the ionospheric correction, the position initially moves down
[15:16] <Laurenceb> then jumps up to something more sensible
[15:17] <Laurenceb> but the actualy correction moves the solution down 8 meters and about 4 meters further away from the true position
[15:17] <Laurenceb> if I just do some trig based on the sat positions, I get to within a meter of the true position
[15:18] <Laurenceb> I think the reason its not working is the pseudoranges are all out by quite a bit,and it happens that the solution is quite accurate
[15:18] fergusnoble (n=fergusno@fn217.quns.cam.ac.uk) returned to #highaltitude.
[15:19] <SpeedEvil> The position is too low?
[15:20] <Laurenceb> yes, by 2.5m with no ionospheric
[15:20] <Laurenceb> and about 10 with
[15:20] <SpeedEvil> is it 'pushed away' from the correct horizontal position on the direction of the weak sat?
[15:21] <Laurenceb> not really
[15:21] <SpeedEvil> I'm wondering if that's got bad multipath
[15:21] <SpeedEvil> :/
[15:21] <Laurenceb> it gets pushed down
[15:21] <Laurenceb> then when I set about 10m of ionosphere, it suddenly jumps up
[15:21] <Laurenceb> but theres about 4m of ionosphere
[15:21] <Laurenceb> depending on zenith angle
[15:22] <SpeedEvil> what's the cause of the ionosphere? Is it just refractive index?
[15:22] <Laurenceb> yeah
[15:23] <Laurenceb> but its coused by free electrons
[15:23] <Laurenceb> so the refractive index is very frequency dependant
[15:23] <SpeedEvil> rainbows in the microwave...
[15:24] <SpeedEvil> I wonder if there is any measurable delay between the top and the bottom of the frequency spectrum of the 2MHz wide GPS signal
[15:25] <Laurenceb> probably not with a patch ant
[15:25] <SpeedEvil> How would you do that - fft and fiddle with the phase?
[15:25] <SpeedEvil> oh yeah - that'll have an affect too.
[15:27] <Laurenceb> hmm clock rate is around -7.5m per ms
[15:28] <Laurenceb> -7.38 to -7.4
[15:28] <SpeedEvil> you mean your clock error?
[15:28] <SpeedEvil> that's what - 1.5Hz or so?
[15:28] <SpeedEvil> 1500Hz
[15:28] <Laurenceb> 25us/second
[15:29] <Laurenceb> clock drift
[15:29] <Laurenceb> its a but big
[15:29] <Laurenceb> *bit big
[15:31] <Laurenceb> about an order of magnitude too large
[15:31] <Laurenceb> dont you think?
[15:34] <Laurenceb> oh crap...
[15:34] <Laurenceb> I think its effectively tied into gps time
[15:34] <Laurenceb> as its working off each prn transmitted from the sats
[15:34] <Laurenceb> that would explain the drift
[15:42] <Laurenceb> god this stuff is confusing
[15:46] <ShellEvil> :/
[15:47] <Laurenceb> ... ok so you tie into the sats time with the dll
[15:47] <Laurenceb> each correlation operation processes one ms of data from each satellite
[15:48] <hallam> Laurenceb: check the websvn for the new data file, Gmail didn't appreciate 80MB
[15:48] <Laurenceb> k
[15:48] <Laurenceb> thanks
[15:48] <Laurenceb> hallam: I've got a receiver clock offset drift of 25ppm
[15:48] <ShellEvil> a drift?
[15:49] <ShellEvil> you mean per ms?
[15:49] <Laurenceb> which seems too high
[15:49] <Laurenceb> yes
[15:49] <ShellEvil> that's insane.
[15:49] <Laurenceb> this is whats confusing me
[15:49] <Laurenceb> yeah its got a TCXO on the board
[15:49] <ShellEvil> Unless it's really not a drift, but horrible phase noise
[15:49] <Laurenceb> no
[15:49] <Laurenceb> I'm trying to get my head around what I'm measureing
[15:50] <Laurenceb> I find the delta time in each position solution, then track the change
[15:50] <ShellEvil> Do you happen to have a nice spectral analyser around?
[15:51] <Laurenceb> maybe...
[15:51] <ShellEvil> I was wondering about connecting the clock to it
[15:51] <Laurenceb> hmm
[15:51] <Laurenceb> I'd think about whats happening first
[15:51] <Laurenceb> also its hallams clock
[15:51] <ShellEvil> I'd also want to check the power supply stability on the USB side
[15:51] <ShellEvil> ah
[15:54] Action: ShellEvil stabs digikey.
[15:55] Last message repeated 1 time(s).
[15:55] <ShellEvil> frequency stability list for crystals - 0.25ppm 0.28ppm 0.50ppm 1.5ppm 100ppm
[15:55] Action: ShellEvil sighs
[15:55] <Laurenceb> 100ppm ?!
[15:56] <ShellEvil> yes - they don't sort sensibly
[15:56] <hallam> it's a txco
[15:56] <hallam> or at least an osc of some kind
[15:56] <ShellEvil> oh
[15:56] <hallam> because there's only one lead to the chip
[15:56] <Laurenceb> yeas, it should be better than 25ppm
[15:56] <hallam> right
[15:56] <hallam> the power supply is possibly crap, because it's laptop USB
[15:56] <ShellEvil> I would expect 3 orders of magnitude better than that at 1ms
[15:56] <ShellEvil> maybe 5
[15:56] <Laurenceb> I'm getting confused about what time we are using
[15:56] <hallam> but explain what you mean by the drift?
[15:56] <ShellEvil> 4 I mena
[15:56] <Laurenceb> I dont know what I'm measureing
[15:57] <hallam> if you're measuring code phase then you're not really using the local clock at all
[15:57] <Laurenceb> as borres code is confusing
[15:57] <Laurenceb> I take the delta time in each position solution
[15:57] <Laurenceb> then look at th edrift
[15:57] <hallam> local clock could come in when you try to measure code phase accurate to a lot better than a chip
[15:57] <hallam> what delta time is that?
[15:57] <ShellEvil> hallam: the power supply isn't laptop USB - it should be on the downside of a 3.3V regulator of some sort
[15:57] <Laurenceb> but borres code has each channel go along the filte
[15:57] <Laurenceb> *file
[15:58] <Laurenceb> so...
[15:58] <hallam> ShellEvil: right, but there might be ground noise or something
[15:58] <ShellEvil> hallam: sure - it's how it's implemented
[15:58] <Laurenceb> I think it a misunderstanding on my part
[15:58] <ShellEvil> hallam: you werent' using a very long cable were you?
[15:58] <hallam> draw diagrams on paper
[15:58] <hallam> no
[15:58] <hallam> it was a cheap mobile phone cable though
[15:59] <Laurenceb> isnt there an ms of sat time between each position solution?
[15:59] <ShellEvil> hallam: shouldn't really matter - I've seen wierd stuff when the volts drops below ~3.8 or so.
[15:59] <hallam> and I've measured my laptop's USB voltage to be <4.5 before now
[15:59] <Laurenceb> not ground time?
[15:59] <Laurenceb> me too
[15:59] <Laurenceb> mine has hdd noise on it
[15:59] <hallam> Laurenceb: if the position solutions are aligned with the PRNs, yes
[15:59] <Laurenceb> anyway
[15:59] <Laurenceb> I'm confused
[15:59] <Laurenceb> are they?
[15:59] <ShellEvil> you have doppler if you're aligning to the sats
[15:59] <Laurenceb> in which case... which sats
[15:59] <hallam> no you don't
[16:00] <hallam> doppler doesn't make time go at a different rate
[16:00] <Laurenceb> hallam: also... your code, how does it avoid the different channels drifting apart?
[16:01] <hallam> it just means you're changing phase
[16:01] <Laurenceb> dont you have to jump an entire prn at some point
[16:01] <hallam> Laurenceb: you have to explain that a bit more
[16:01] <hallam> nah
[16:01] <Laurenceb> to stop them drifting apart?
[16:01] <Laurenceb> well you track the prn
[16:01] <hallam> my code_phase variable just keeps counting on past 1023 chips
[16:01] <Laurenceb> then prn from one sats moving at a different rate to another
[16:01] <ShellEvil> hallam: doppler makes time as recieved from the sat vary is what I mean
[16:01] <hallam> but it would need a long run of data to get to that point
[16:02] <Laurenceb> sure
[16:02] <Laurenceb> and it doesnt matter on a pc
[16:02] <Laurenceb> but on an embedded application with little ram
[16:02] <hallam> shouldn't matter in the embedded case either
[16:02] <Laurenceb> dont you need to skip a whole prn?
[16:02] <hallam> i can afford a few doubles per channel
[16:02] <Laurenceb> doubles?
[16:02] <hallam> I don't know exactly what you mean, this kind of thing is hard to talk about over IRC
[16:02] <Laurenceb> yeah
[16:02] <Laurenceb> grr
[16:03] <hallam> I have to go explain to my senior tutor why I've been building a GPS receiver instead of doing massively overdue coursework
[16:03] <hallam> ttyl
[16:03] <Laurenceb> say you are tracking one sat thats moving away from you and one towards you
[16:03] <Laurenceb> cya
[16:03] Nick change: hallam -> hallam|screwed
[16:03] <Laurenceb> hallam: print off some pretty graphics
[16:04] <Laurenceb> http://imagebin.org/37035
[16:04] <Laurenceb> well ms paint pretty
[16:06] <Laurenceb> hmm it looks like in borres code the dlls dont stay aligned
[16:06] <Laurenceb> each one reads throug the data file independantly, and the data output is a the time of each prn code
[16:07] <ShellEvil> Hmm. I diddn't realise 1.5ppm txco's were so cheap. ($4)
[16:08] <Laurenceb> neat
[16:08] <ShellEvil> http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=478-4821-1-ND
[16:08] <ShellEvil> 2.5ppm ones are _common_
[16:08] <Laurenceb> we need 16.368MHz
[16:09] <ShellEvil> http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=535-9615-2-ND
[16:09] <ShellEvil> $3 - 2.5ppm
[16:09] <ShellEvil> I can use 2
[16:09] <ShellEvil> You can have the other 998
[16:09] <ShellEvil> http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=535-9615-1-ND
[16:10] <ShellEvil> $7 - which isn't at all bad
[16:12] <ShellEvil> Ah - that's even a tcvxo
[16:12] <Laurenceb> ok I've just looked at the numbers... if you keep hallams idea working for several hours
[16:13] <Laurenceb> then sats may drift off in different directions by orders of 10^4km
[16:13] <ShellEvil> idea?
[16:13] <Laurenceb> say 10ms
[16:13] <Laurenceb> travel time
[16:13] <Laurenceb> so your DMA will start filling up with around 10ms of data
[16:13] <ShellEvil> not been closely reading
[16:14] <Laurenceb> a few 100KB ast the most
[16:14] <ShellEvil> you mean what happens if you get a buffer overrun?
[16:14] <Laurenceb> but... the calculated positions of the sats will be wrong
[16:14] <Laurenceb> by tens of m
[16:14] <Laurenceb> SpeedEvil: ok, you have DMA for collecting the data
[16:14] <Laurenceb> then you have apointer for each channel
[16:14] <Laurenceb> and read in data to be processed
[16:15] <Laurenceb> assuming your DLL remains locked, your pointer will drift through
[16:15] <Laurenceb> the circular buffer
[16:15] <ShellEvil> you mean if the buffeer is sized so that it's an integer number of chips?
[16:15] <Laurenceb> its a bit compilcated, you setup circular buffers
[16:15] <Laurenceb> no
[16:16] <Laurenceb> you have a large cicular buffer in external SDRAM
[16:16] <Laurenceb> DMA incoming data into it
[16:16] <Laurenceb> then you create a cicular buffer
[16:16] <Laurenceb> now lets define some address space within the buffer
[16:16] <Laurenceb> with TOP as the incoming data pointer
[16:17] <ShellEvil> What's this for - to make it less hard-realtime?
[16:17] <Laurenceb> the individual trackers will be below the TOP
[16:17] <Laurenceb> yes
[16:17] <Laurenceb> so it can say run under linux
[16:17] <Laurenceb> blackfin linux or something
[16:18] <Laurenceb> problem is, if the individual trackers renmain locked, they will drift about relative to TOP
[16:18] <ShellEvil> you only care if they start to drift out of range
[16:18] <ShellEvil> get within 25% of the top or bottom of the buffer
[16:18] <Laurenceb> yes
[16:18] <ShellEvil> if they do that, you stop for 1ms, or do extra work on that channel for 2ms
[16:19] <Laurenceb> that in itself isnt a big issue
[16:19] <Laurenceb> its not a lot of ram
[16:19] <Laurenceb> BUT your positions will be out
[16:19] <ShellEvil> Err - no
[16:19] <Laurenceb> as you are using data recorded at different times
[16:19] <ShellEvil> Doesn't matter
[16:19] <Laurenceb> so the sats will have moved
[16:19] <Laurenceb> oh... guess you can use the buffer position
[16:19] Action: ShellEvil ponders how to best explain.
[16:19] <ShellEvil> yes
[16:19] <ShellEvil> that
[16:19] <ShellEvil> and known clock rate
[16:20] <Laurenceb> arg iuts so confusing
[16:20] <Laurenceb> or unknown in this case
[16:20] <ShellEvil> what's unknown?
[16:20] <Laurenceb> your clock
[16:20] <ShellEvil> No it's not.
[16:20] <Laurenceb> well not extremely accurately
[16:20] <ShellEvil> Not once you've got a position
[16:20] <Laurenceb> ok... guess that one is solved
[16:21] <ShellEvil> you have a position - you then use that to solve for time.
[16:21] <Laurenceb> yeah anyway
[16:21] <Laurenceb> to return to the present problem...
[16:21] <ShellEvil> And you use repeated time solutions against your local clock for local clock rate
[16:21] <ShellEvil> sorry.
[16:21] <Laurenceb> I'm solving for time
[16:21] <Laurenceb> :P
[16:21] Action: ShellEvil spins off at tangents.
[16:21] <Laurenceb> yeah thats what I did to get 25ppm
[16:21] <ShellEvil> you're not recalculating that at 1KHz?
[16:22] <Laurenceb> yes
[16:23] <ShellEvil> That's going to be extremely noisy - you have ~25m of noise at 1KHz you said?
[16:23] <ShellEvil> Or was it 6
[16:23] <Laurenceb> 6
[16:23] <Laurenceb> but the clock rate isnt too noisy
[16:23] <Laurenceb> 7.38 to 7.40
[16:24] <Laurenceb> arg someone shutdown the ee cluster
[16:24] <Laurenceb> no debian workstations to ssh into
[16:24] <Laurenceb> :-/
[16:25] <Laurenceb> grr
[16:25] <ShellEvil> I note that 1 million * c/(6*1000) = ~25
[16:26] <Laurenceb> right
[16:26] <Laurenceb> I think I' may have worked it out
[16:26] <Laurenceb> the position solver wors on an array of data from the tracking code
[16:27] <Laurenceb> its an array of place in to file for each prn repitiin and SV
[16:28] <Laurenceb> so the nav solver goes through and for each row of repitions finds pseudoranges
[16:28] <Laurenceb> now thats not 1ms between nav solver runs
[16:28] <Laurenceb> it doepends on the sat geometery
[16:28] <Laurenceb> e.g. if all sats are moving away from us, its obviously not
[16:29] <Laurenceb> in reality its more complex, but you get the idea
[16:29] <Laurenceb> follow?
[16:29] <ShellEvil> I follow that you can't simply average the range-rates to get clock, yes.
[16:29] <Laurenceb> hmm kind of the same thing
[16:30] <ShellEvil> You've got to solve for position, and get the time from there, which is I think what you're meaning.
[16:30] <Laurenceb> now... how can I find clock
[16:30] rjharrison (n=rharriso@gateway.hgf.com) joined #highaltitude.
[16:30] <Laurenceb> yeah
[16:30] <Laurenceb> I gues I have to find the position at two times
[16:31] <ShellEvil> Or more and curve fit
[16:31] <Laurenceb> or rather use the number of samples between two position fixes
[16:31] <Laurenceb> yeah
[16:31] <Laurenceb> this is complicated by the fact each channel is moving through the file at a different rate
[16:31] <Laurenceb> but if I take two points say 1 second apart
[16:32] <ShellEvil> You need to work out another in the file
[16:32] <ShellEvil> this is also moving through the file at a similar rate to the sats - but not quite - it's the time at your position
[16:32] <Laurenceb> guess I could just use one sat
[16:32] <Laurenceb> so near the beginning, find the range to that sat
[16:33] <Laurenceb> so at a subframe start from that sat, find the range to that sat
[16:33] <Laurenceb> i.e. actual range
[16:34] <Laurenceb> then at a later time, find the number of samples the tracker for the sat has gone through
[16:34] <Laurenceb> no -then at a later subframe start, find the number of samples the tracker for the sat has gone through
[16:34] <Laurenceb> compensate using the new calculated range
[16:35] <Laurenceb> then compensate using special relativity
[16:35] <Laurenceb> then loop over sats and average
[16:35] <Laurenceb> argggg
[16:35] <Laurenceb> I'm not coding that
[16:35] <jcoxon> oooooo i've made my antenna better :-)
[16:36] <Laurenceb> tell all
[16:36] <rjharrison> jcoxon: So it works :P
[16:36] <ShellEvil> Room-temperature-superconductor goodness?
[16:36] <jcoxon> well i added a new cable and bnc plug, much smarter
[16:37] <jcoxon> managed to pick up a repeater 31miles away which i used to not be able to receive
[16:38] <jcoxon> this is my moxon antenna rather then my 2m GP
[16:38] <jcoxon> right time to kick CUSF so i can test it!
[16:39] <jcoxon> also the SWR meter shows no bars which is good
[16:40] <rjharrison> Sound great
[16:40] <rjharrison> Give them a good kick I would like to get some tracking in too
[16:40] <jcoxon> hehe i don't think you can rush them to tell the truth
[16:41] <rjharrison> PS the current sentance from the tracker would be helpful if fergusnoble wakes up
[16:41] <ShellEvil> yeah
[16:42] <ShellEvil> s/build/build for a price/
[16:42] <ShellEvil> oops
[16:44] <jcoxon> perhaps i should build a 2m one :-p
[16:44] <ShellEvil> Antennas are fun.
[16:44] <ShellEvil> They're so easy.
[16:45] <Laurenceb> guess so
[16:45] <Laurenceb> did hallam find a database of gps dopplers?
[16:46] <Laurenceb> I remember he was looking at the doppler shifts
[16:47] <ShellEvil> xephem --version
[16:48] <Laurenceb> oh course
[16:48] <Laurenceb> just thinking the simple way to do this is using dopplers
[16:52] <ShellEvil> delta-range surely
[16:52] <ShellEvil> Or even use the elements
[17:04] <Laurenceb> http://hackaday.com/2009/01/29/uhf-power-harvesting/
[17:04] <Laurenceb> very interesting
[17:04] <Laurenceb> annoyingly I cant view the papae
[17:08] RocketBoy (n=Steve@217.47.75.27) left irc: Read error: 60 (Operation timed out)
[17:13] <hallam|screwed> Laurenceb: interesting that your censor proxy lets you see hackaday but not hacks.mit.edu
[17:13] Nick change: hallam|screwed -> hallam
[17:18] <Laurenceb> he
[17:19] <Laurenceb> did you get that pdf?
[17:19] <Laurenceb> oh how did it go with the tutor?
[17:26] josepharmbruster (n=josephar@45.144.119.70.cfl.res.rr.com) joined #highaltitude.
[17:28] <hallam> which pdf?
[17:29] <hallam> eh, not great
[17:29] <hallam> I'll deal
[17:29] <Laurenceb> :P
[17:29] <Laurenceb> I linked it earlier
[17:29] <Laurenceb> the official gps docs
[17:30] <Laurenceb> I've just been looking at the residuals
[17:31] <Laurenceb> but of course there arent any, as there 4 degrees of freedom
[17:31] <Laurenceb> durrrr
[17:31] <Laurenceb> I need 5 sats
[17:31] <Laurenceb> I'll have a go this evening, I'm off to buy some coax and build a moxon now
[17:32] <Laurenceb> cya
[17:33] Laurenceb (i=83e34f19@gateway/web/ajax/mibbit.com/x-e4cfc682fd9d0846) left irc: "http://www.mibbit.com ajax IRC Client"
[17:45] RocketBoy (n=Steve@217.47.75.27) joined #highaltitude.
[17:46] jcoxon (n=jcoxon@host86-158-31-172.range86-158.btcentralplus.com) left irc: "Leaving"
[17:47] natrium42 (i=natrium4@CPE000625d867e2-CM0014045885be.cpe.net.cable.rogers.com) joined #highaltitude.
[17:55] <hallam> Hi natrium42, RocketBoy
[17:55] <natrium42> hi
[17:57] <hallam> SpeedEvil / ShellEvil : http://www.srcf.ucam.org/~cuspaceflight/websvn/listing.php?repname=CUSF&path=%2FHenryGNSS%2F newdata.rar
[17:58] <ShellEvil> Thanjkts!
[17:58] rjharrison (n=rharriso@gateway.hgf.com) left irc:
[17:59] <hallam> (sorry, Mibbit makes the PMs hard to notice)
[18:03] <ShellEvil> np
[18:07] <ShellEvil> What's the data format on that? Same as the first?
[18:13] <hallam> yeah, 1 bit per byte, IQIQIQIQIQ
[18:14] <ShellEvil> 4MHz?
[18:14] <hallam> 8.1438 MSamples/s
[18:14] <ShellEvil> ah
[18:14] <hallam> IF 38.5kHz
[18:15] <hallam> PRNs 25 11 13 23 32 in view that I was able to track, don't know about others
[18:15] <hallam> the data format is horribly inefficient I know, but Laurence didn't want to modify the Borres software
[18:18] <ShellEvil> np. At least it's easy
[18:20] <hallam> I'm kind of impressed that RAR can get it down below one bit per bit
[18:20] <ShellEvil> 1 bit/bit entropy would mean it's fullscale I think
[18:21] <ShellEvil> any less may mean lower signal level
[18:21] <hallam> full scale?
[18:21] <hallam> oh right
[18:21] <hallam> or at least, lower noise level
[18:21] <ShellEvil> yes
[18:21] <hallam> the datasheet for the front end claims that the AGC attempts to keep the average level such that it's above the ADC threshold about 1/3 of the time
[18:22] <ShellEvil> Do you have any signal number? Is the average GPS signal of a strong signal 0.117 bits or whatever?
[18:22] <ShellEvil> ah
[18:22] <ShellEvil> so in a jam-free environment, with several GPS sats up, maybe a bit less than the above random number
[18:22] <hallam> I don't know, I think it's pretty rare for the signal to be above the thermal floor
[18:23] <hallam> but you understand this stuff a lot better than I do
[18:28] <hallam> alright, bedtime
[18:28] Nick change: hallam -> hallam|zzz
[18:29] <ShellEvil> night
[18:59] G8KHW (n=Steve@217.47.75.27) joined #highaltitude.
[19:07] RocketBoy (n=Steve@217.47.75.27) left irc: Read error: 110 (Connection timed out)
[19:27] Laurenceb (n=laurence@dyres221-140.surrey.ac.uk) joined #highaltitude.
[19:37] rjharrison (n=rharriso@80.176.172.227) joined #highaltitude.
[19:37] <Laurenceb> stupid maplins were closed
[19:37] <Laurenceb> is there a launch tomorrow?
[20:05] <Laurenceb> wheres the cu spaceflight cubversion repositiory?
[20:12] <Laurenceb> fergusnoble: ping
[20:22] <Laurenceb> nvm got it
[20:31] Bluenarf (n=Paul@apollo.paulsnet.org) joined #highaltitude.
[20:31] Nick change: Bluenarf -> EI5GTB
[21:25] <Laurenceb> wow tar.bz2 can compress raw data down to 0.87 bits per data byte
[21:25] <Laurenceb> thats pretty mental
[21:36] <fergusnoble> Laurenceb and everyone else, we have decieded not to launch tomorrow
[21:43] <Laurenceb> fairdoos
[21:43] <Laurenceb> I dont have an antenna anyway
[21:45] <fergusnoble> ok, sorry, too much wind and too much work
[21:47] <Laurenceb> yeah
[21:48] <Laurenceb> I'm still trying to work out how tar.bz2 managed that compression feat
[21:49] <Laurenceb> I guess as theres a filter limiting the bandwidth to about 3MHz, it could theoretically get to less than 0.5 bins/sample
[21:55] <Laurenceb> http://uk.youtube.com/watch?v=ke6P5qF072k&NR=1
[21:56] <Laurenceb> its a typical person off #electronics
[22:06] EI5GTB (n=Paul@apollo.paulsnet.org) got netsplit.
[22:06] EI5GTB (n=Paul@apollo.paulsnet.org) returned to #highaltitude.
[22:47] Hiena (n=Hiena@81.93.195.181.datatrans.hu) left irc: "-=Halt! Hammerzeit!=-"
[22:59] <Laurenceb> hallam|zzz : http://maps.google.co.uk/maps?f=q&source=s_q&hl=en&geocode=&q=52+12%27+7.57%27%27+N+0+7%27+11.09%27%27+E&sll=52.202117,0.119741&sspn=0.000186,0.000603&ie=UTF8&ll=52.202128,0.119808&spn=0.000186,0.000603&t=h&z=21&iwloc=addr
[23:01] G8KHW (n=Steve@217.47.75.27) left irc: "Leaving"
[23:02] <SpeedEvil> lau: and as the signal level deviates from max, entropy drops too
[23:06] Xenion (n=robert@p579FCE53.dip.t-dialin.net) left irc: "Verlassend"
[23:09] <SpeedEvil> lau: seems an odd position
[23:09] <SpeedEvil> Laurenceb: but...
[23:11] <Laurenceb> maybe he intended the tree as a landmark
[23:12] <SpeedEvil> Or the 'target' has GPS jammers
[23:12] josepharmbruster (n=josephar@45.144.119.70.cfl.res.rr.com) left irc: Read error: 113 (No route to host)
[23:12] <SpeedEvil> I know damn well I'd want em if I lived there.
[23:14] <Laurenceb> propbably hallams college
[23:15] <SpeedEvil> my bad
[23:15] <SpeedEvil> I thought it was the other downing street.
[23:18] <Laurenceb> http://www.cam.ac.uk/map/v4/drawmap.cgi?mp=main;xx=1900;yy=1040
[23:19] Action: SpeedEvil wonders if there's much misdirected mail.
[23:19] <Laurenceb> close
[23:19] <Laurenceb> a few 100m to the east
[23:20] <SpeedEvil> ?
[23:20] <SpeedEvil> One of the buildings of pembroke colledge would seem to work
[23:22] <Laurenceb> I was think ing the tree
[23:22] <Laurenceb> but I didnt think it was that accurate
[23:22] <Laurenceb> time to look at the residuals
[23:23] <SpeedEvil> There's the big park 300m to the right that'd be obvious - but ...
[23:23] <Laurenceb> yeah
[23:24] <SpeedEvil> NMEA output time.
[23:24] <SpeedEvil> HDOP, VDOP
[23:24] <SpeedEvil> EPE
[23:25] <Laurenceb> nmea ?!
[23:28] <Laurenceb> its pretty cool that the spread of points in 3D is around 2cm standard deviation
[23:28] <Laurenceb> from a line moving in 3D
[23:29] <Laurenceb> looks very hopeful for IMU integration
[23:29] <SpeedEvil> If the cake is not a lie.
[23:29] <Laurenceb> the line wanters about by several meters over the course of seconds
[23:29] <SpeedEvil> you think most of the residual error is iono?
[23:29] <Laurenceb> yeah
[23:30] <Laurenceb> it looks like what you would expect from iono and tropo to an extent
[23:30] <Laurenceb> a lot of it is the DLL settling down
[23:30] <SpeedEvil> How fast/slow is your code?
[23:31] <Laurenceb> as in runtime?
[23:31] <Laurenceb> its all in matlab, so it takes about 30 minuts
[23:31] <SpeedEvil> yes
[23:31] <Laurenceb> henrys takes 20 seconds
[23:31] <SpeedEvil> ah
[23:31] Action: SpeedEvil buys intel shares.
[23:31] <Laurenceb> slight difference :P
[23:31] <SpeedEvil> You clearly need a faster computer.
[23:31] <SpeedEvil> does matlab do multi-core?
[23:32] <Laurenceb> not unless theres some options I havent discovered
[23:33] <Laurenceb> it looks like you 'd have to run this for several minutes to get the dll to settle down
[23:33] <Laurenceb> but then the error would be in the region of 1m rms
[23:33] <Laurenceb> with fluctuations on the scale of 5seconds or more
[23:34] josepharmbruster (n=josephar@45.144.119.70.cfl.res.rr.com) joined #highaltitude.
[23:34] <Laurenceb> so I'm guessing these are caused by the ionosphere, and possibly the troposphere
[23:34] <SpeedEvil> That sort-of-agrees with some 'real' GPSs I've used
[23:34] <SpeedEvil> After 60-120 seconds they get a bit more accurate
[23:34] <Laurenceb> interestingly its on the timescale of wind gusting in the troposphere
[23:34] <Laurenceb> yeah
[23:34] <Laurenceb> that wont be the cause here, as it was calm
[23:35] <Laurenceb> but wind will add to the effect
[23:35] <SpeedEvil> the iono frame is only transmitted once per 12mins?
[23:35] <Laurenceb> 12.5
[23:35] <SpeedEvil> yeah
[23:35] <Laurenceb> I just looked up some TEC maps
[23:35] <Laurenceb> and did a bit of trig
[23:35] <Laurenceb> but I dont know when this data was recorded :-/
[23:35] <SpeedEvil> have you looked at the skew of the 12.5 min broadcasts?
[23:36] <SpeedEvil> TOW
[23:36] <Laurenceb> ah
[23:36] <Laurenceb> good point
[23:37] <SpeedEvil> skew - as in - is the iono broadcast at more or less the same time, optimally spread around over sats so you get it at different times, or completely random
[23:40] <Laurenceb> it'll be at the same time I think
[23:40] <Laurenceb> its subframe 4, page 18
[23:40] <Laurenceb> subframes are cynced
[23:41] <SpeedEvil> I know it's the same time in the message. I don't know if they are skewed over sats
[23:41] <SpeedEvil> ah
[23:41] <Laurenceb> but I'm not sure if they sqew the pages
[23:41] <Laurenceb> good point
[23:41] <Laurenceb> that wouldbt a good plan
[23:41] <SpeedEvil> There are arguments for both
[23:41] <SpeedEvil> makes it more robust to recieve if in parallel, and faster if arranged right
[23:42] <Laurenceb> I maight loosen up the DLL so it locks on faster
[23:44] <SpeedEvil> genetic algorithms!
[23:44] <SpeedEvil> though 30min per iteration may make it painful
[23:44] <Laurenceb> at least half of the noise is the pll at the moment
[23:44] <Laurenceb> i.e. a couple of cm
[23:44] <Laurenceb> think I can live with that
[23:45] <SpeedEvil> where is this 'couple of cm' noise coming out?
[23:45] <Laurenceb> in the position fix
[23:45] <Laurenceb> an 1KHz
[23:45] <SpeedEvil> is that the ms-ms position fix
[23:45] <Laurenceb> yes
[23:45] <SpeedEvil> in that the PLLs drift at 2000cm/s
[23:46] <SpeedEvil> and the resultant position varies at that speed
[23:46] <Laurenceb> the 1KHz fix starts about 30m off, then snakes its way it, and spirals about the true fix
[23:46] <Laurenceb> the noise in the individal fixes about this line is a few cm
[23:46] <SpeedEvil> So that's 'really' not 2cm fixes - it's 2cm after the PLL filter?
[23:47] <Laurenceb> and the noise in the line relative to the likely looking path is about 1m
[23:47] <Laurenceb> they go through the nav filter
[23:47] <Laurenceb> they are valid solutions
[23:47] <SpeedEvil> What's the raw code-phase noise?
[23:47] <Laurenceb> <1m
[23:47] <Laurenceb> theres 6 sats
[23:48] <Laurenceb> so it goes down quite a bit
[23:48] <SpeedEvil> be interesting to find if the position is real.
[23:48] Action: SpeedEvil pokes hallam|zzz.
[23:48] <Laurenceb> it gives a 6m error with his previous position
[23:49] <SpeedEvil> Are the signal levels higher?
[23:49] <Laurenceb> but that seems to be what you would expect given the ionospheric conditions
[23:49] <SpeedEvil> ah
[23:49] <Laurenceb> here there 6 sats and orders of mag higher
[23:49] Action: SpeedEvil tries to remember the quietest time.
[23:49] <Laurenceb> also lower noise
[23:49] <Laurenceb> night
[23:49] <SpeedEvil> it's mid-morning isn't it?
[23:49] <Laurenceb> no
[23:49] <Laurenceb> after midnight
[23:50] <Laurenceb> 3am approx
[23:50] Action: SpeedEvil wonders what he was thinking of.
[23:50] <SpeedEvil> Position solutuion almost seems too good :)
[23:51] <Laurenceb> its almost down to the theoretical limit
[23:51] <Laurenceb> thats 3 to 4 meters
[23:52] <Laurenceb> but that assumes good DOP and signal levels
[23:52] <SpeedEvil> where does the noise come from in the theoretical limit?
[23:52] <Laurenceb> sat position
[23:52] <SpeedEvil> residual iono/tropo
[23:52] <Laurenceb> sat clock errors, ionospheric, and tropo
[23:53] <Laurenceb> approx 2m,1m,2m,0.3m
[23:54] <Laurenceb> surey stuff uses L1 and L2 then postprocesses with weather data and precise ephemeris
[23:54] <Laurenceb> for mm level accuracy
[23:55] Tigga (n=chatzill@pc-232-235-103.magd.cam.ac.uk) joined #highaltitude.
[00:00] --- Sat Jan 31 2009