[00:00] <Laurenceb> so... taking the complex correlation implies that the cross correlation has an imaginary component
[00:00] <Laurenceb> which doesnt make intuitive sense
[00:01] <hallam> right
[00:01] <hallam> that's what I don't totally get
[00:01] <hallam> should you just throw away the imaginary part of it?
[00:01] <hallam> Laurenceb, your code was using the absolute value
[00:01] <Laurenceb> what does the imaginary part look like?
[00:01] <Laurenceb> hallam: yeah
[00:01] Action: SpeedEvil imagines a purple llama.
[00:01] <hallam> that's what I was trying to ask
[00:01] <Laurenceb> I didnt really think about it
[00:01] <Laurenceb> hmm I dont have matlab here
[00:02] <hallam> one sec, I'll plot some
[00:02] <Laurenceb> I'll have a go with octave
[00:02] <Laurenceb> hallam: try it with real
[00:02] <hallam> it doesn't seem to give as good SNR with real
[00:03] <hallam> the peaks don't stand out as much
[00:03] <Laurenceb> weird
[00:03] <Laurenceb> oh hang on
[00:03] <Laurenceb> our input is complex
[00:04] <Laurenceb> so if our local osc is off, maybe that makes the cross correlation complex
[00:04] <Laurenceb> yeah that will be why
[00:05] <Laurenceb> so you can use the angle of the correlation peak to impliment a PLL
[00:06] <Laurenceb> oh $%^
[00:06] Action: Laurenceb as had a flux leak
[00:06] <Laurenceb> this stuff is expensive
[00:08] RocketBoy (n=Steve@ left irc: "Leaving"
[00:11] <hallam> Laurenceb: http://uploads.mibbit.com/up/6MRiy7dh.png
[00:12] <hallam> they seem to be pretty randomly distributed in phase
[00:13] <Laurenceb> yeah, but they roughly form a circle
[00:13] <hallam> that just means the magnitude is roughly constant
[00:13] <Laurenceb> as you dont have a locked PLL, that makes sense
[00:13] <hallam> they don't go round the circle
[00:14] <Laurenceb> you wouldnt expenct that
[00:14] <Laurenceb> you could be off by up to 500Hz
[00:14] <hallam> http://uploads.mibbit.com/up/9AT6ove0.png
[00:15] <hallam> 500Hz in doppler?
[00:15] <Laurenceb> yes
[00:15] <hallam> hm
[00:16] <hallam> what if I use a lot more frequency bins to find the doppler more accurately? (still only looking at 1ms at a time)
[00:16] <fergusnoble> erm, the lassen seems to be getting a time fix atm with no antenna connected
[00:16] <fergusnoble> wierd
[00:16] <Laurenceb> hallam wow
[00:16] <Laurenceb> classic non locked PLL
[00:16] <Laurenceb> nice
[00:16] <hallam> hm
[00:16] <Laurenceb> that plot is awsome
[00:16] <fergusnoble> actually, ill try power cycling it
[00:17] <Laurenceb> fergus: it has a habit of screwing up if you run it inside a lot
[00:17] <hallam> I wash my hands of lassens
[00:17] <Laurenceb> fergus: you need to interrupt power from the battery
[00:17] <hallam> Laurenceb: you mean it's actually supposed to be like that? :P
[00:17] <Laurenceb> yeah, thats really impressive
[00:17] <hallam> I'm going to run it over 100ms instead of 20
[00:18] <hallam> actually that was integrating over 2ms at a time, not 1, but that shouldn't make too much difference, right?
[00:18] <Laurenceb> you can see a databit as well
[00:18] <Laurenceb> all manner of awsome
[00:18] <hallam> I was wondering if that was what that was
[00:18] <hallam> let's see if it works over a longer period
[00:18] <Laurenceb> lassens are cool
[00:19] <Laurenceb> they run TSIP and have loads of nice settings
[00:19] <hallam> they fuck up too much and have lousy interference rejection
[00:19] <Laurenceb> true
[00:19] <hallam> they do give more data out than your average module
[00:19] <Laurenceb> but you can input a gyro measurement
[00:20] <Laurenceb> - something I discovered the other day
[00:20] <Laurenceb> you can also get raw data from the tracking loops
[00:21] <hallam> oh really, phase and stuff?
[00:21] <hallam> that's cool
[00:21] <hallam> pity about the dynamics limits
[00:21] <Laurenceb> yeah
[00:21] <hallam> but I guess that would let you do DGPS?
[00:21] <Laurenceb> I wonder if they are only in the position code
[00:22] <Laurenceb> so maybe over the dynamics limits you can still get raw data... perhaps
[00:22] <Laurenceb> maybe is you loaded screwy ephemeris so it couldnt find a position you could go over the dynamics limits
[00:23] <Laurenceb> mine manged to do that by itself - it was tracking 10 sats, but no pos fix
[00:23] <Laurenceb> *if
[00:23] <hallam> laurence: http://uploads.mibbit.com/up/qxmtCTJr.png
[00:23] gordonjc1 (n=gordonjc@symmetria.fi) joined #highaltitude.
[00:23] gordonjc1 (n=gordonjc@symmetria.fi) left irc: Client Quit
[00:24] <hallam> do you think that's a nav bit at about 65ms?
[00:24] <Laurenceb> and 125
[00:25] <Laurenceb> I'd seriously suggest a tracking loop
[00:25] <hallam> this is so much more fun than work
[00:25] <hallam> I'm such a nerd
[00:25] <Laurenceb> so have acquisition as a function that returns some matrix
[00:25] <Laurenceb> lol
[00:26] <hallam> ok, talk to me about how to do a tracking loop
[00:26] <Laurenceb> well... I dont fully understand
[00:26] <Laurenceb> as the PLL loops I've seen have noise bandwidths of ~20hz
[00:26] <hallam> returns a matrix of doppler, code phase, correlation?
[00:26] <Laurenceb> but you may be off by 500Hz
[00:26] <Laurenceb> maybe yeah
[00:27] <Laurenceb> so one main function calls the acquisition code
[00:27] <hallam> just out of interest I'm going to run it with narrower freq bins
[00:27] <Laurenceb> then feeds its return value to the tracker
[00:28] <Laurenceb> the function upconvert in your code, where does that come from?
[00:28] <Laurenceb> did you put that in a seperate file?
[00:28] <hallam> matlab has it
[00:28] <hallam> er, maybe it's in the signal processing toolbox
[00:29] <Laurenceb> ok
[00:29] Action: Laurenceb only has octave
[00:29] <hallam> it just turns [a b c] into [a 0 0 b 0 0 c 0 0] if you call it with parameter 3
[00:29] <hallam> you can use the commented-out fft thing instead if you want
[00:29] <Laurenceb> erm zeros?
[00:29] <hallam> it's just faster than doing a humungous fft
[00:30] <Laurenceb> oh I kind of see
[00:30] <Laurenceb> you do a smaller fft?
[00:30] <hallam> if fft([a b c d]) = [e f g h]
[00:30] <hallam> then fft([a b c d a b c d]) = 2*[e 0 f 0 g 0 h 0]
[00:30] <hallam> and it's faster to do the latter
[00:30] <Laurenceb> yeah
[00:31] <hallam> especially if it's repeated 50 times
[00:34] <hallam> Laurenceb: you have pm (since mibbit doesn't tell you)
[00:34] <Laurenceb> so, in the tracking code, I'd have an early, late and prompt copy of the code
[00:36] <fergusnoble> has anyone ever had the lassen spit out wierd floating point numbers for lat and lon when its not got a good fix
[00:37] <fergusnoble> with very large or small exponents
[00:37] <fergusnoble> like blah e-207
[00:38] <fergusnoble> i say its not got a good fix but its actuall got 5 sats
[00:38] <fergusnoble> very stange gps
[00:41] <Laurenceb> fergus: only when my code was wrong endian
[00:41] <fergusnoble> Laurenceb: yeah ive had some endian issues in the past
[00:41] <fergusnoble> but it does give the correct position most of the time
[00:41] <Laurenceb> in my experience you get a lock within 3 seconds of aquiring 4 sats
[00:41] <fergusnoble> so im pretty sure its not a major error in converting the floating point stuff
[00:42] <Laurenceb> and with ephemeris backed up, it should get a lock in less than a minute
[00:42] <fergusnoble> yeah
[00:42] <Laurenceb> mine usually takes 12.5 to 15 minutes with wiped SRAM
[00:43] <hallam> that'd be a whole almanac then
[00:43] <Laurenceb> where were we.... tracking loops
[00:44] <fergusnoble> yeah ,sorry to interject with my dodgy gps
[00:44] <Laurenceb> so you have an early, late, prompt gate
[00:44] <Laurenceb> np
[00:44] <hallam> before we talk about them for a minute can we spend a bit more on the acq graphs?
[00:44] <Laurenceb> sure
[00:44] Action: Laurenceb goes to make some coffee
[00:45] <hallam> thanks :) http://uploads.mibbit.com/up/QcvxZRJL.png
[00:45] <hallam> that's with 10Hz frequency bins
[00:47] natrium (n=alexei@CPE000625d867e2-CM0014045885be.cpe.net.cable.rogers.com) joined #highaltitude.
[00:48] <hallam> so shouldn't that mean that it knows the freq pretty well?
[00:48] <hallam> or is it just not possible to get the frequency that accurate with only 1ms of data
[00:49] <SpeedEvil> modulo knowing local cock fuccky
[00:49] <SpeedEvil> local clock fully
[00:49] Action: SpeedEvil sighs
[00:49] <hallam> sure, but for purposes of phase lock
[00:49] <hallam> I don't understand why the angle(maximum correlation) graph is still so jaggedy
[00:50] <hallam> don't get why it's not just the nav message with a little noise
[00:52] jiffe97 (n=jiffe2@ got netsplit.
[00:52] dh (i=dh@bsd.ee) got netsplit.
[00:52] Laurenceb (n=laurence@dyres221-35.surrey.ac.uk) got netsplit.
[00:52] gregHome (n=gleblanc@ got netsplit.
[00:52] SpeedEvil (n=jfkjdjkf@tor/regular/SpeedEvil) got netsplit.
[00:52] Tygrys^ (i=tygrys@moo.pl) got netsplit.
[00:52] kc0wys (n=kc0wys@75-130-209-194.dhcp.stls.mo.charter.com) got netsplit.
[00:52] Ebola (i=ebola@unaffiliated/ebola) got netsplit.
[00:52] borism_ (n=boris@195-50-197-56-dsl.krw.estpak.ee) got netsplit.
[00:52] rjharrison (n=rharriso@ got netsplit.
[00:52] fergusnoble (n=fergusno@fn217.quns.cam.ac.uk) got netsplit.
[00:52] epictetus (n=pattm@static-71-174-73-53.bstnma.fios.verizon.net) got netsplit.
[00:52] smealum (n=smealum@smea.servebeer.com) got netsplit.
[00:52] gordonjcp (n=gordonjc@symmetria.fi) got netsplit.
[00:54] akawaka (n=akawaka@external.treyarch.com) left irc: "Leaving"
[00:54] gordonjcp (n=gordonjc@symmetria.fi) returned to #highaltitude.
[00:54] akawaka (n=akawaka@ joined #highaltitude.
[00:54] Laurenceb (n=laurence@dyres221-35.surrey.ac.uk) returned to #highaltitude.
[00:54] kc0wys (n=kc0wys@75-130-209-194.dhcp.stls.mo.charter.com) returned to #highaltitude.
[00:54] gregHome (n=gleblanc@ returned to #highaltitude.
[00:54] SpeedEvil (n=jfkjdjkf@tor/regular/SpeedEvil) returned to #highaltitude.
[00:55] smealum (n=smealum@smea.servebeer.com) returned to #highaltitude.
[00:55] epictetus (n=pattm@static-71-174-73-53.bstnma.fios.verizon.net) returned to #highaltitude.
[00:55] jiffe97 (n=jiffe2@ returned to #highaltitude.
[00:55] dh (i=dh@bsd.ee) returned to #highaltitude.
[00:55] <hallam> warg netsplit
[00:55] fergusnoble (n=fergusno@fn217.quns.cam.ac.uk) returned to #highaltitude.
[00:55] rjharrison (n=rharriso@ returned to #highaltitude.
[00:55] borism_ (n=boris@195-50-197-56-dsl.krw.estpak.ee) returned to #highaltitude.
[00:55] Ebola (i=ebola@unaffiliated/ebola) returned to #highaltitude.
[00:55] fergusnoble (n=fergusno@fn217.quns.cam.ac.uk) left irc: Client Quit
[00:55] fergusnoble (n=fergusno@fn217.quns.cam.ac.uk) joined #highaltitude.
[00:55] fergusnoble (n=fergusno@fn217.quns.cam.ac.uk) left irc: Client Quit
[00:55] fergusnoble (n=fergusno@fn217.quns.cam.ac.uk) joined #highaltitude.
[00:55] <fergusnoble> bloody freenode netsplitting
[00:56] natrium42 (n=alexei@CPE000625d867e2-CM0014045885be.cpe.net.cable.rogers.com) left irc: Connection timed out
[00:57] Tiger^ (i=tygrys@moo.pl) joined #highaltitude.
[01:01] <Laurenceb> hallam: thats the phase from each acquisition?
[01:02] <hallam> yes
[01:03] Tygrys^ (i=tygrys@moo.pl) got lost in the net-split.
[01:03] <hallam> phase of the maximum correlation
[01:03] <Laurenceb> hmm if mush be swappping bins
[01:03] <hallam> ?
[01:03] <Laurenceb> ok maybe not
[01:03] <Laurenceb> hmm
[01:04] <Laurenceb> well it doesnt look noisy, so I think we can presume its finding the correct bin
[01:04] <hallam> the scatter plot is fairly circular as before
[01:05] <Laurenceb> so it should be possible to feed one acquisition straight into a tracket
[01:05] <Laurenceb> *tracker
[01:05] <hallam> right
[01:06] <hallam> but at the moment I'm not seeing how the tracker is going to be able to output nav data
[01:06] <Laurenceb> its not
[01:06] <Laurenceb> its a less computationally demanding way to get good phase and doppler
[01:06] <hallam> right
[01:06] <hallam> that's what I thought
[01:07] <Laurenceb> I'd suggest a spacing of +-2 samples
[01:07] <hallam> so is it just that I have the wrong doppler for some reason?
[01:07] <hallam> what do you mean by that?
[01:07] <Laurenceb> for the early,late
[01:07] <Laurenceb> I think its jumping across bins
[01:08] <Laurenceb> maybe
[01:08] <hallam> across freq bins? that's easy to check
[01:08] <hallam> but I don't think it is
[01:08] <Laurenceb> yeah
[01:08] <Laurenceb> ok
[01:08] <Laurenceb> well in that case you can only be 5Hz out
[01:08] <Laurenceb> it doesnt look like that
[01:09] <Laurenceb> hmm maybe its at the boundary between two bins
[01:11] <hallam> I take that back, it is hopping between bins
[01:11] <Laurenceb> I'd investigate if its jumping between bins
[01:11] <hallam> well sort of
[01:12] <Laurenceb> is there a pattern?
[01:12] <hallam> 35550, 35500, 35400, 35400, 35538, 35538, 35550, 35563, 35563, 35550, 35563, 35550, 35550, 35550
[01:13] EI5GTB (n=Paul@apollo.paulsnet.org) left irc: Connection reset by peer
[01:13] <hallam> I think probably the correlation/freq curve is too flat and it's being swamped by noise
[01:14] <hallam> should I try fixing it to one frequency?
[01:14] <Laurenceb> yeah its odd that there seems to be a pattern to the phase
[01:14] <Laurenceb> nah
[01:15] <Laurenceb> just a sec I'll take a look in borre et al
[01:16] <Laurenceb> ok
[01:17] <Laurenceb> the least computationally demanding is to apply the PRN first
[01:17] <Laurenceb> then multiply by the local osc
[01:18] <Laurenceb> then a sign(imag)*real descriminator
[01:19] <hallam> what's one of those, and give me a bit more context? this is tracking?
[01:19] <Laurenceb> carrier tracking
[01:19] <Laurenceb> so the discriminator measures the error
[01:19] <Laurenceb> this then goes through a loop filter, to the NCO
[01:19] <Laurenceb> numerically controlled oscillator
[01:20] <Laurenceb> as I understand it, a simple loop filter is along the lines of NCO+=discriminator*k+(discriminator-old_discriminator)*l
[01:22] <Laurenceb> those coeffiecents are related to the noise bandwidth and damping ratio of your filter
[01:22] <Laurenceb> but I've forgotten the equationa
[01:22] <Laurenceb> and its not in borre
[01:23] Action: Laurenceb wikipedia
[01:27] <hallam> what does it mean when you do the acquisition correlation over frequency and code phase and get a maximum that is large, but imaginary?
[01:28] <Laurenceb> damping ratio=0.7 and noise bandwidth=60Hz worked well in the book
[01:28] <Laurenceb> the local ocs is out of phase by pi
[01:29] <Laurenceb> I just need to see how that relates to the filter coefficients
[01:29] <hallam> simple as that?
[01:29] <Laurenceb> yes
[01:29] <hallam> ok
[01:30] <fergusnoble> hallam: i know your in a bit of a groove with the gps but i was wondering, the sd card is working well now but im pausing the code when its not writing to yank the card out, obviously you cant do that in use and there is a small chance you could corrupt the fat by yanking the card out while its writing, what do you think a good solution might be?
[01:31] <fergusnoble> maybe a button on the board which can be pressed to inhibit writing or something?
[01:32] <hallam> or turn it off before yanking the card?
[01:32] <hallam> actually what happens if you turn it off while it's writing?
[01:33] <fergusnoble> same as pulling the card
[01:33] <hallam> bums
[01:33] <hallam> clearly the solution is a journalling filesystem
[01:33] <hallam> but failing that, yeah probably a button
[01:33] <fergusnoble> i guess you could buffer and only write like once per second and flash an led while writing then time your pulling of the card
[01:34] <hallam> I think we should have a button anyway, so maybe holding it for a few s could stop it
[01:34] <fergusnoble> but thats not great if you want to write a lot of stuff
[01:34] <hallam> should have an activity led deffo
[01:34] <fergusnoble> yeah, ok
[01:34] <fergusnoble> could even just be tied to the sd cards CS pin
[01:34] <fergusnoble> but i agree some buttons would be nice
[01:35] <fergusnoble> i think the chances of actually pulling it while its writing something critical is low, but still its not good design that you could wreck the flights data just by removing the sd card
[01:36] <fergusnoble> ok, im off to bed
[01:37] <fergusnoble> good gps'in
[01:37] <Laurenceb> cya
[01:37] <hallam> night
[01:44] <Laurenceb> hmm I cant work out how to get to the coefficients from bandwidth and damping ratio
[01:47] <Laurenceb> ok... so we want some NCO function that takes an arguent in rads/sec
[01:47] <Laurenceb> and returns a look up table
[01:50] <Laurenceb> guess you could just try trial and error
[01:55] <Laurenceb> ok, think I might have it
[01:56] <Laurenceb> just a sec I'll work it through on paper
[01:57] <hallam> cool
[01:57] <hallam> I'm just making the acquisition code into a tidy function
[02:00] <Laurenceb> l=0.168
[02:02] <Laurenceb> k=0.0118
[02:04] <Laurenceb> NCO+=discriminator*k+(discriminator-old_discriminator)*l
[02:13] <Laurenceb> hmm no upsample in octave
[02:17] <hallam> shouldn't take long to write
[02:17] <Laurenceb> actually maybe mn_upsample does it
[02:18] <Laurenceb> hows it coming on?
[02:18] <hallam> I just finished making it nice
[02:18] <hallam> about to start the tracking, though I don't really know where to begin
[02:19] <Laurenceb> as we have acess to -ive numbers ect
[02:19] <Laurenceb> id suggest a early-late signal
[02:19] <hallam> ?
[02:19] <hallam> oh
[02:20] natrium42 (n=alexei@CPE000625d867e2-CM0014045885be.cpe.net.cable.rogers.com) joined #highaltitude.
[02:20] <hallam> early-late in carrier phase
[02:20] <Laurenceb> no
[02:20] <Laurenceb> PRN
[02:20] <hallam> ok
[02:20] <Laurenceb> so maybe have +-2 samples
[02:20] <hallam> 1/4 of a chip
[02:20] <Laurenceb> yeah
[02:21] <Laurenceb> then correlate each ms of data with that
[02:21] <Laurenceb> using . product
[02:21] <Laurenceb> after multiplying by the local osc
[02:22] <Laurenceb> then take the sign(imag)*real and feed it into the costas loop filter
[02:22] <hallam> do I loop over the milliseconds?
[02:22] <Laurenceb> yes
[02:23] <Laurenceb> and real as a DLL filter input
[02:24] <Laurenceb> I'm trying to find good DLL filter coefficients
[02:25] <Laurenceb> maybe just something basic
[02:25] <Laurenceb> book says just linea PLL
[02:26] <Laurenceb> so I imagine they mean PRN_clock_freq+=k*real(early_late_dot_product)
[02:27] <Laurenceb> where k in that case would be -ive
[02:28] <Laurenceb> in carrier aiding you use the carrier frequency to help generate the PRN clock
[02:28] <hallam> wait a minute, is there one early and one late PRN, or one "early-late" PRN? (don't know what the latter means)
[02:29] <Laurenceb> just loop through the PRN for your sat taking earl_late=cacode(n)-cacode(mod((n+4),1023));
[02:29] <SpeedEvil> you take a copy of one PRN sequence, and delay it by half or a quarter, or whatever.
[02:29] <SpeedEvil> or that
[02:29] Action: SpeedEvil goes back to sleep
[02:30] <hallam> wait wtf
[02:30] natrium (n=alexei@CPE000625d867e2-CM0014045885be.cpe.net.cable.rogers.com) left irc: Read error: 110 (Connection timed out)
[02:30] <hallam> sorry, still not getting it :(
[02:30] <Laurenceb> it saves you doing two correlations
[02:30] <Laurenceb> you could do two correlations and subtract
[02:31] <Laurenceb> or you could correlate with that
[02:31] <hallam> okay
[02:31] <Laurenceb> after you've done this you have to correlate with a prompt code
[02:31] <Laurenceb> then plot the results in the complex plain for each ms
[02:31] <hallam> do I want to be shifting the offset into the data, or the PRN? would shifting the offset into the data be better for aligning with nav transitions?
[02:32] <hallam> this really is a complex plain in the ms ::
[02:32] <hallam> :P
[02:32] <Laurenceb> hallam: cant you just dot product in matlab
[02:32] <hallam> yeah
[02:32] <Laurenceb> so data.*early_late
[02:32] <hallam> oh ok I keep forgetting we're correlating not cross-correlating
[02:32] <Laurenceb> well data.*local_osc
[02:32] <Laurenceb> first
[02:33] <hallam> ok
[02:33] <hallam> I was wondering though whether it would be better to make an early-late version of the data rather than the PRN
[02:33] <Laurenceb> nah
[02:33] <hallam> ok
[02:33] <Laurenceb> you can reuse the early late this way
[02:34] <Laurenceb> so first step make the early_late and prompt matrices
[02:34] <hallam> ok, but it goes a bit squiffy on nav bit transitions doesn't you?
[02:34] <hallam> doesn't it*
[02:34] <hallam> ok
[02:34] <Laurenceb> hallam: no
[02:34] <hallam> er, matrices?
[02:34] <Laurenceb> 1x1023
[02:34] <hallam> right
[02:34] <Laurenceb> well a costas loop doesnt mind +-180 degrees
[02:35] <hallam> but the transition could come in the middle of your millisecond
[02:35] <hallam> giving 0 correlation
[02:35] <Laurenceb> oh crap
[02:35] <Laurenceb> yeah
[02:36] <Laurenceb> thats why this stuff is run of fpgas
[02:36] <hallam> if you earlylate the data instead, you shouldn't get that problem
[02:36] <Laurenceb> so you can run the filters ect all the time
[02:36] <Laurenceb> I dont see why
[02:37] <hallam> you always compare to the original unshifted PRN
[02:38] <hallam> and your tracking loop keeps the data in phase with it
[02:38] <hallam> nav bit transitions always come aligned with the start of the PRN
[02:38] <Laurenceb> yeah
[02:38] <Laurenceb> ok
[02:39] <Laurenceb> but you dont need to early-late the data to do that
[02:39] <Laurenceb> you just align your tracker
[02:39] <hallam> hm, right, I guess not
[02:39] <hallam> ok
[02:39] <Laurenceb> based on the acquisition data
[02:39] <hallam> so the "state variable" is the offest into the data
[02:40] <Laurenceb> you dont always grab 1023*8 samples
[02:40] <hallam> sometimes 1023*8+1, sometime 1023*8-1
[02:40] <Laurenceb> the variable I called prn_clock_freq
[02:41] <Laurenceb> yeah more or less
[02:41] <Laurenceb> that determines how much you grab- enough for one prn cycle
[02:42] <Laurenceb> for the first iteration, you can intialise prn_clock_freq using the doppler
[02:42] <Laurenceb> so (doppler-38,000)/1.5GHz
[02:43] <Laurenceb> is the fractional clock change
[02:44] <Laurenceb> then start back at the begining of the data set
[02:44] <hallam> this is going to end up being a bit weird, because the tracking loops will by synced to the satellites rather than to the receiver's time
[02:44] <Laurenceb> and chuck a section of data to alogn with the PRN code
[02:44] <hallam> so one SV will end up at a different time to another
[02:44] <Laurenceb> yes
[02:44] <Laurenceb> its a little odd
[02:45] <Laurenceb> but should work faster in matlab
[02:45] <Laurenceb> we're kind of making this up as we go along
[02:45] <hallam> I wonder how the other GPS SDR people do it
[02:45] <Laurenceb> the design in the book is very slow
[02:45] <Laurenceb> but will run on a fpga well
[02:45] <hallam> does it go chip by chip?
[02:48] <Laurenceb> hmm I'm confused
[02:48] <hallam> me too
[02:48] <hallam> GPS is very clever
[02:48] <Laurenceb> the filters are in software on the core
[02:48] <Laurenceb> hmm
[02:49] <Laurenceb> maye the counters are dumped when the PRN code generator overflows
[02:49] <Laurenceb> that probably explains it
[02:49] <Laurenceb> so each tracker has a counter and a register
[02:50] <Laurenceb> when the prn generator overflows the counter for I_prompt or whatever is dumped into the register
[02:50] <Laurenceb> and maybe an interrupt is triggered or whatever
[02:50] <Laurenceb> then the arm7 (or processor of choice) comes along and grabs the I_prompt
[02:51] <Laurenceb> most of the designs I've seen have all the filters in a high priority task running under an RTOS
[02:51] <hallam> do they still work in ~1ms chunks?
[02:51] <Laurenceb> so maybe the task just loops through the dump lines looking for valid data
[02:52] <Laurenceb> so no they dont in that case
[02:52] Action: hallam doesn't get it yet
[02:52] <Laurenceb> but the task can run at a constant rate of 1Khz or so
[02:52] <Laurenceb> under the RTOS
[02:52] <Laurenceb> ok, so each tracker has 6 counters
[02:53] <Laurenceb> I_early,I_prompt,I_late
[02:53] <Laurenceb> same for q
[02:53] <Laurenceb> in the lassen iq for example, there are 12 of these units (12 channel)
[02:54] Action: hallam just realised why it's called the lassen *iq* ... (carry on)
[02:54] <Laurenceb> each tracker has a NCO and logic gate based PRN generator, with a clock
[02:54] <Laurenceb> hehe
[02:54] <Laurenceb> not sure how the clock works... but anyway
[02:54] <Laurenceb> maybe as simple as a divider running of F_CPU
[02:55] <Laurenceb> anyway when the the prn counter register reaches 1022 and overflows
[02:56] <hallam> the early,prompt,late counters are saved
[02:56] <Laurenceb> it triggers all the I_prompt ect bins to be dumped into sotorage
[02:56] <hallam> and reset to 0
[02:56] <Laurenceb> and a line to the CPU is set
[02:56] <hallam> and the counters multiply-accumulate once for every sample?
[02:56] <Laurenceb> yeah
[02:56] <Laurenceb> or you can reset it to 10ms of you want
[02:56] <hallam> what?
[02:57] <Laurenceb> all these registers are accessable under TSIP (I think)
[02:57] <Laurenceb> god knows how that works... anyway
[02:57] <Laurenceb> by default it boots into 1ms mode
[02:57] <hallam> ok whatever
[02:58] <Laurenceb> anyway theres a task on the RTOS running at 1KHz or so
[02:58] <hallam> ok, that does stuff, hang on a minute
[02:58] <Laurenceb> it looks at the 12 data ready lines
[02:58] <hallam> I just want to be totally clear on how the counters are filled
[02:58] <hallam> every sample time (8MHz in our case),
[02:59] <Laurenceb> yeah, I think so
[02:59] <hallam> the I sample of data is multiplied with the I sample of the early PRN, and added to the early counter
[02:59] <hallam> ditto for the other 5
[02:59] <Laurenceb> IIRC lassen iq is 4MHz
[02:59] <hallam> right?
[02:59] <Laurenceb> yeah
[02:59] <hallam> ok
[02:59] <Laurenceb> after multiplication with the local osc
[02:59] <hallam> right
[03:00] <Laurenceb> so, the rtos ltask loops through all ready data, checking the data ready lines
[03:00] <hallam> so the computer, in its 1kHz control loop, controls the phase and frequency properties of the local osc and of the PRN generator
[03:00] <Laurenceb> then applies loop filters in software
[03:00] <Laurenceb> yeah
[03:00] <hallam> okay
[03:00] <hallam> pretty sure I understand so far
[03:00] <Laurenceb> so we are a little bit different
[03:01] <hallam> well
[03:01] <Laurenceb> as we have no dedicated hardware
[03:01] <Laurenceb> so we have to read from a file
[03:01] <hallam> I was thinking it might be best to code it in the same way to start with
[03:01] <Laurenceb> thats effectively what we're doing
[03:02] <hallam> so we're going to ignore the fact that we could go back and forth in time in order to get better results with less data
[03:02] <Laurenceb> yeah, to start with at least
[03:02] <hallam> sounds good
[03:02] <Laurenceb> so our file reads are sinced with the sat time
[03:03] <Laurenceb> we read one prn cycle at a time
[03:03] <hallam> weeel
[03:03] <hallam> we could still do it sample by sample
[03:04] <Laurenceb> which would take ages
[03:04] <hallam> but then I guess we can't take advantage of MATLAB's fast dot product
[03:04] <Laurenceb> dot producting will be fast
[03:04] <Laurenceb> yeah
[03:04] <hallam> ok so we read one PRN cycle's worth of samples, which may not be the same as 1023 samples
[03:05] <Laurenceb> 8*1023 or therabouts
[03:05] <hallam> sorry yeah
[03:11] <Laurenceb> you can just read 1ms samples, but the PRN phase would have to be constantly changing
[03:11] <Laurenceb> it would be like you were moving sat several Km/s
[03:11] <Laurenceb> so the filter wouldnt work as well
[03:12] <hallam> not just moving but accelerating
[03:13] <Laurenceb> yeah
[03:13] <Laurenceb> good point
[03:14] <Laurenceb> I'm just wondering how the 1PPS works...
[03:14] <Laurenceb> I guess its tied into one or more of the trackers...
[03:14] <Laurenceb> with some delay counter
[03:15] <hallam> with the delay synced to the nav message bits, and then to the TOW
[04:31] <SpeedEvil> and the position
[04:31] <SpeedEvil> can't have time without position
[04:46] <hallam> Laurenceb: still awake?
[04:47] <Laurenceb> am now
[04:47] <Laurenceb> hallam
[04:48] <Laurenceb> was asleep most of thee evening
[04:48] <Laurenceb> maybe I should try sleeping at normal times :P
[04:48] <hallam> hehe
[04:48] <Laurenceb> hows it going?
[04:49] <hallam> so I have it calculating early,prompt,late correlations (complex) for every PRN cycle
[04:49] <hallam> how do I adjust the PRN and carrier periods and phases based on those?
[04:49] <Laurenceb> neat, not early-late?
[04:49] <hallam> well I can change it to early-late
[04:49] <Laurenceb> we have the advantage of signed datatypes
[04:49] <hallam> but I have all 3 at the moment
[04:49] <Laurenceb> ok
[04:50] <Laurenceb> so you need loop filters
[04:50] <hallam> right
[04:50] <hallam> hook a bro up?
[04:52] <Laurenceb> you need a numerically controlled oscillator
[04:53] <Laurenceb> sorry my machine froze
[04:53] <hallam> I think I have the NCO
[04:53] <Laurenceb> as I understand it, it has to take arguments in rads/sec
[04:53] <hallam> easily fixed
[04:54] <Laurenceb> then you have a discriminator of the form sign(imag)*real
[04:54] <hallam> this is for the PRN clock or the carrier?
[04:54] <Laurenceb> operating on the propmt bin
[04:54] <hallam> ok
[04:55] <Laurenceb> so... you need a loop filter between it and the NCO
[04:55] <Laurenceb> which is what I worked out earlier
[04:55] <hallam> which NCO is this, carrier or prn?
[04:55] <Laurenceb> do you have the scrollback?
[04:55] <Laurenceb> carrier
[04:55] <hallam> zeusbot does
[04:55] <hallam> ok
[04:56] <Laurenceb> I guess we could try with a seperate PRN clock
[04:56] <Laurenceb> but there are ways to combine the two
[04:56] <hallam> let me show you the code I have at the moment
[04:56] <Laurenceb> thats carrier aiding
[04:56] <Laurenceb> k
[04:56] <hallam> http://pastebin.com/d18354b97
[04:57] <Laurenceb> my machine is rather unstable, gnuplot ate 4GB of swap
[04:57] <hallam> eit
[04:57] <hallam> would be nice to downsample those mesh plots before drawing them, I think
[04:57] <hallam> I guess I only have one NCO at the moment, the carrier one
[04:57] <Laurenceb> yeah
[04:58] <Laurenceb> especially with gnuplot
[04:58] <hallam> even matlab gets a bit narky with some of the big ones
[04:58] <Laurenceb> even my core duo with 4GB ram struggle to plot them in matlab
[04:58] <Laurenceb> gnuplot on my laptop....
[05:00] <Laurenceb> as I understand it, if you just want a early/late based prn tracker
[05:00] kc0wys (n=kc0wys@75-130-209-194.dhcp.stls.mo.charter.com) left irc:
[05:01] <Laurenceb> then the loop filter is first order, in other words, prn_clock+=early-late_bin*k;
[05:01] <Laurenceb> dunno a good value for k
[05:01] <hallam> with k=0.0118
[05:01] <hallam> ?
[05:01] <Laurenceb> no, thats for the carrier loop
[05:01] <hallam> oh right
[05:02] <Laurenceb> borre has lots of good info on that
[05:02] <hallam> let's not worry about the prn loop right now
[05:02] <Laurenceb> yeah, it looks a lot easier to get right
[05:02] <hallam> the prompt correlation dies after 20ms at the moment (with no loop filter), which must be due to carrier phase I think
[05:02] <Laurenceb> yeah
[05:03] <Laurenceb> that sounds about right, off by 50hz or so
[05:04] <Laurenceb> so you dump from the beginning of the file to match up with a PRN staaaaart?
[05:04] <hallam> yeah
[05:04] <Laurenceb> grr time to kill gnuplot :-/
[05:04] <hallam> so are we changing carrier_phase or carrier_freq or both, based on the early and late bins?
[05:05] <Laurenceb> frequency
[05:05] <hallam> ok
[05:06] <Laurenceb> hmm but you dont want a glitch in the phase
[05:06] <hallam> I think I can make it start where it left off
[05:06] <Laurenceb> your going to have to use the last value of the previous NCO table to start the new one
[05:06] <Laurenceb> yeah
[05:07] <Laurenceb> then the step in phase between each sample is just prop to frequency
[05:09] <hallam> arg this is confusing
[05:10] <hallam> not sure if I need to stretch the carrier and the data to match the prn or just the data
[05:11] <hallam> yes I think I do
[05:11] <Laurenceb> I think most ASIC/fpga designs use 6 integration bins as that means it can be done with no siigned or complex datatypes
[05:12] <Laurenceb> but we can do it with two, as we have both
[05:12] <Laurenceb> hallam: no, stretch the PRN to the data
[05:12] <Laurenceb> hence the PRN clock frequency
[05:13] <Laurenceb> prn phase increases with each sample
[05:13] <Laurenceb> you round the phase to the nearest integer
[05:13] <Laurenceb> between 1 and 1023
[05:14] <Laurenceb> then use the resulting value as the PRN
[05:14] <Laurenceb> i.e. lookup that number
[05:14] <hallam> but remember the nav bit transition
[05:14] <Laurenceb> doesnt matter
[05:14] <hallam> we need to keep working with PRN-length chunks
[05:14] <Laurenceb> sure
[05:14] <Laurenceb> hence the clock frequency
[05:14] <Laurenceb> you initialise that using the doppler
[05:15] <Laurenceb> if you plot the prompt integration bin on a complex plain, it should be a load of dots around +-1
[05:16] <hallam> when the tracking works, yeah
[05:16] <Laurenceb> if you plot the real, you will see the nav bits
[05:16] <hallam> right
[05:16] <hallam> when it works
[05:16] <hallam> so
[05:16] <Laurenceb> :P
[05:16] <hallam> I always grab 8184 data samples?
[05:16] <Laurenceb> no
[05:17] <Laurenceb> oh thats waht you mean by stretching
[05:17] <Laurenceb> sorry
[05:17] <hallam> ok, I sometimes grab fewer or more
[05:17] <Laurenceb> yeah
[05:17] <hallam> as controlled by the prn DLL
[05:17] <hallam> right?
[05:17] <Laurenceb> yeah
[05:18] <hallam> so having got those 8180 data bits, I can either stretch them to 8184 and correlate with the PRN, or leave them alone but squish the PRN
[05:18] <hallam> I guess if I stretch them, I also have to stretch the LO
[05:18] <Laurenceb> yeah
[05:19] <Laurenceb> so stretch the prn
[05:19] <Laurenceb> 1023/PRN_clock_freq
[05:19] <hallam> yeah I guess so
[05:19] <hallam> ok
[05:20] <Laurenceb> erm 1023*ADC_sample_rate/PRN_clock_freq
[05:20] <Laurenceb> is how many to get
[05:21] <hallam> how many data samples
[05:21] <Laurenceb> ^ that many :P
[05:21] <hallam> right
[05:21] <hallam> I'm sorry I'm so slow
[05:21] <Laurenceb> complex samples that is
[05:22] <hallam> yeah
[05:22] <Laurenceb> it is rather complex :P
[05:22] <Laurenceb> excuse the pun
[05:24] <hallam> I guess I should get the floor of that number
[05:26] <Laurenceb> then prn_phase+=1023*PRN_clock_freq/ADC_sample_rate
[05:27] <Laurenceb> no
[05:27] <hallam> don't get that
[05:27] <Laurenceb> then prn_phase+=PRN_clock_freq/ADC_sample_rate
[05:28] <Laurenceb> round prn_phase to the nearest integre mod 1023
[05:28] <hallam> and do what with it?
[05:28] <Laurenceb> and use that to create your PRN for the sample
[05:28] <Laurenceb> its now decoherent is phase and doppler
[05:28] <Laurenceb> *in
[05:29] <hallam> can't I precompute the PRN and PRNearly-late and just stretch/squish it to however many samples I grabbed?
[05:29] <Laurenceb> I'm not sure
[05:29] <Laurenceb> i'd rather continue from where you left off
[05:29] <hallam> don't understand the prn phase stuff, since I thought the objective was to keep it locked to 0
[05:30] <Laurenceb> oh crap
[05:30] <Laurenceb> yeah
[05:30] <Laurenceb> ok
[05:30] <hallam> I think it's okay
[05:30] <Laurenceb> so you start PRN_phase from zero
[05:30] <hallam> I'd rather not have a prn_phase variable at all
[05:30] <Laurenceb> then use it to stretch the precomputed PRN
[05:31] <hallam> and just keep it locked by adjusting prn_clock_freq
[05:31] <Laurenceb> its just to do th stretch
[05:31] <hallam> maybe we're talking about the same thing in different ways
[05:31] <hallam> gimme a min
[05:33] <Laurenceb> you could create some stretch function I guess, then pass the aerly late and prompt PRN thon
[05:33] <Laurenceb> no
[05:33] <Laurenceb> stretch first
[05:33] <Laurenceb> then make the aerly-late
[05:33] <Laurenceb> less work
[05:34] <hallam> I think it's less work to stretch on the fly
[05:34] <hallam> but the stretching is very cheap
[05:34] <Laurenceb> are there built in functions?
[05:35] <Laurenceb> cool, so we know how many samples to get, and we stretch the prn
[05:35] <Laurenceb> and local osc is continuing from where it left off
[05:36] <Laurenceb> cool
[05:36] <hallam> interp1
[05:36] <Laurenceb> ok
[05:36] <hallam> in 'nearest' mode
[05:36] <Laurenceb> yeah, we want +-1 ideally
[05:37] <Laurenceb> maybe if it interpolates transitions slightly
[05:37] <Laurenceb> ie 1,1,1,1,1,0,-1,-1 ect
[05:38] <hallam> let's just stick with nearest
[05:38] <hallam> that gives +-1
[05:38] <Laurenceb> but no rounding of the waveform
[05:38] <hallam> yeah
[05:38] <Laurenceb> ok
[05:38] <hallam> it's just a stretch in time domain
[05:39] natrium42 (n=alexei@CPE000625d867e2-CM0014045885be.cpe.net.cable.rogers.com) left irc: Read error: 60 (Operation timed out)
[05:40] <Laurenceb> oh we need to initialise the prn_clock_freq using the doppler
[05:41] <Laurenceb> so the doppler/L1_freq=PRN_shift/PRN_cloc
[05:42] <Laurenceb> PRN_clock=1023000
[05:42] <hallam> yeah
[05:43] <Laurenceb> PRN_clock_freq=1023*(1+doppler/L1)
[05:43] <hallam> do we really have to do that, can't we just start it as 1023000?
[05:43] <Laurenceb> PRN_clock_freq=1023000*(1+doppler/L1)
[05:43] <hallam> it's not like it changes very quickly
[05:43] <Laurenceb> I'm not sure
[05:43] <Laurenceb> yeah
[05:43] <Laurenceb> may as well try without
[05:44] <Laurenceb> L1=1575.42e6
[05:45] <hallam> yeah
[05:45] <hallam> so for a typical doppler that would start it as something like 1023003
[05:46] <Laurenceb> yeah, not a big issue
[05:46] <Laurenceb> needs to correct itself in a few hundered ms
[05:51] <hallam> hrmrmrmrmmm
[05:51] <hallam> I wonder if it would be better to junk all this stretching
[05:52] <hallam> and keep in code-phase lock just by throwing away samples
[05:52] <hallam> or, er, going back in time
[05:52] <Laurenceb> good point
[05:53] <hallam> is that the same thing I was suggesting ages ago?
[05:53] <hallam> I don't think it's quite the same
[05:53] <Laurenceb> no
[05:53] <Laurenceb> 300*1000=300km/s
[05:53] <hallam> right
[05:53] <Laurenceb> so you'll never have to move by more than one chip
[05:53] <hallam> right
[05:54] <hallam> or even more than one sample
[05:54] <Laurenceb> so chuck 0,1,or 2 samples
[05:54] <hallam> surely -1, 0 or 1?
[05:54] <Laurenceb> yeah, but that makes file use harder?
[05:55] <hallam> I read the whole file in anyway
[05:55] <hallam> does 0, 1 or 2 work?
[05:55] <Laurenceb> oh ok
[05:55] <hallam> I don't see how chucking 2 is the same as moving back 1
[05:55] <Laurenceb> it will
[05:55] <hallam> how?
[05:55] <Laurenceb> if you alogn the prn right
[05:55] <Laurenceb> so chucking one is the same as no shift
[05:55] <hallam> ?
[05:56] <hallam> oh, so you usually chuck 1 every time
[05:56] <Laurenceb> i.e. a lenght 1021
[05:56] <Laurenceb> ye
[05:56] <hallam> do you mean length 1022?
[05:56] <Laurenceb> then you can use fread
[05:56] <Laurenceb> hmm
[05:57] <Laurenceb> if its 1022 and you chuck 2
[05:57] natrium42 (n=alexei@CPE000625d867e2-CM0014045885be.cpe.net.cable.rogers.com) joined #highaltitude.
[05:57] <Laurenceb> guess you could lookup the lengh of the data
[05:57] <hallam> ok, I don't quite understand yet
[05:58] <Laurenceb> so I chuck one, then correlate with the last 1023*8-1
[05:59] <Laurenceb> I can shift along by chucking none, or 2
[05:59] <hallam> so you're always reading 1023*8-1 samples
[05:59] <Laurenceb> yes
[05:59] <hallam> and correlating against a length 1023*8 code?
[05:59] <Laurenceb> crap
[05:59] <Laurenceb> durrrrrrrrrrrrr
[06:00] <Laurenceb> ok
[06:00] <Laurenceb> yes +-1`
[06:00] <hallam> maybe correlating against a 1023*8 code truncated to 1023*8-1? (rather than stretched)
[06:00] <Laurenceb> that was what I was saying
[06:00] <hallam> so you also chuck the first sample of the code, but you do that *every* time, whereas you vary how many data sampels you chuck
[06:00] <hallam> do I have that right?
[06:01] <Laurenceb> hmm
[06:01] <Laurenceb> yeah maybe it does work
[06:01] <hallam> I think it does
[06:01] <Laurenceb> yeah I think you can have it so you chuck one data sample
[06:01] <Laurenceb> all the time
[06:01] <Laurenceb> and switch to 0 or 2
[06:01] <hallam> so not all the time?
[06:02] <Laurenceb> well all the time apart from when you make adjustments using the DLL
[06:02] <hallam> ok
[06:02] <hallam> so
[06:02] <hallam> precompute PRN, PRNearly-late
[06:02] <hallam> chuck 1 sample from the start of each
[06:03] <Laurenceb> yeah, correlate with the last 1022 bits
[06:03] <Laurenceb> 1022*8
[06:03] <Laurenceb> yeah
[06:03] <Laurenceb> argg
[06:03] <hallam> 1023*8-1 ?
[06:03] <Laurenceb> 1023*8-1
[06:03] <hallam> ok
[06:03] <Laurenceb> yeah
[06:04] <Laurenceb> then have some number call it PRN_phase_offset
[06:05] <Laurenceb> PRN_phase_offset+=PRN_freq_offset
[06:05] <Laurenceb> each iteration
[06:05] <hallam> when it reaches some threshold you chuck
[06:05] <Laurenceb> PRN_freq_offset+=k*real(early-late);
[06:05] <Laurenceb> yeah
[06:06] <Laurenceb> so, to use proper units for these
[06:07] <Laurenceb> PRN_phase_offset+=PRN_freq_offset*0.001
[06:07] <Laurenceb> if PRN_phase_offset>0.5
[06:07] <Laurenceb> ect
[06:07] <Laurenceb> i.e. +-0.5 limits
[06:09] <hallam> when you chuck 2, you subtract 1 from PRN_phase_offset
[06:09] <hallam> and when you chuck 0, you add 1 to PRN_phase_offset
[06:09] <hallam> right?
[06:09] <Laurenceb> or you dont bother
[06:09] <hallam> no, you have to, don't you?
[06:10] <Laurenceb> and you correlate with the first 1023*8-1 or 1023*8-2
[06:10] <hallam> isn't it always 1023*8-1?
[06:11] <Laurenceb> if you chuck 2, you have 102388-2
[06:11] <hallam> I thought you chucked 0,1 or 2, then read exactly 1023*8-1
[06:11] <Laurenceb> so you corrleate with the first 1023*8-2
[06:11] <Laurenceb> oh
[06:12] <hallam> if you do that then you don't change the prn phase
[06:12] <Laurenceb> ok, thats simpler
[06:12] <hallam> now how does this work with the carrier generation?
[06:12] <Laurenceb> so yeah
[06:13] <Laurenceb> you adjust PRN_phase_offset
[06:13] <Laurenceb> the carrier generation is completely seperate
[06:13] <hallam> I've been including a sample index term in the carrier generation
[06:13] <hallam> but I guess I should make it so it doesn't
[06:15] <Laurenceb> no, you just have a complex number to store the NCO output at the end of each sampleperiod
[06:15] <hallam> I'm generating the carrier as a vector
[06:16] <Laurenceb> yeah
[06:16] <Laurenceb> so you save the last element of the vector
[06:16] <hallam> so I should generate 1023*8 samples of carrier, and chuck the first one?
[06:16] <Laurenceb> then use it to start off the next vector
[06:16] <hallam> or generate 1023*8-1 samples of carrier
[06:16] <Laurenceb> you chuck the first one
[06:17] <Laurenceb> or if your clever
[06:17] <Laurenceb> generate 1023*8-1
[06:17] <hallam> carrier=exp(i*carrier_freq*(2:Nsp)/carrier_period + carrier_phase);
[06:17] <Laurenceb> and use a matching phase term
[06:17] <Laurenceb> to avoid glitches
[06:17] <Laurenceb> oh crap
[06:17] <hallam> you want a glitch, and then to chuck it
[06:17] <Laurenceb> when you skip 0 or 2
[06:18] <Laurenceb> its going to create a glitch
[06:18] <hallam> you gotta skip them in the carrier too?
[06:18] <Laurenceb> yeah
[06:18] <Laurenceb> thats how to fix it
[06:18] <hallam> that's no biggie
[06:18] <hallam> I'll just leave the t term in the carrier generation
[06:18] <Laurenceb> the % increase in calculations in small
[06:19] <Laurenceb> yeah, if you create LO to match the samples, then chuck it with the samples, it'll be glitch free
[06:19] <hallam> hrm
[06:20] <Laurenceb> so run the PLL, generate the LO lookup, then depending on the DLL, chuck some from the front
[06:24] <hallam> ok
[06:25] <hallam> back to the PLL
[06:25] <hallam> the discriminator is disc=sign(corrPrompt)*real(corrPrompt);
[06:25] <hallam> doesn't care about early-late? that's just for the DLL?
[06:31] <Laurenceb> yeah
[06:31] <Laurenceb> ok... I was reading borre
[06:32] <Laurenceb> I think instead of early-late, we should go for early and late
[06:32] <Laurenceb> i.e. sperate
[06:32] <Laurenceb> then use a noncoherent DLL
[06:33] <Laurenceb> which takes the form abs(early)^2-abs(late^2)/abs(early)^2-abs(late)^2
[06:33] <Laurenceb> then PRN_phase_offset+=k*discriminator_output
[06:34] <Laurenceb> and limits on Phase_offset of +-1
[06:34] <Laurenceb> with corrections of 0.5 each timewe make a step
[06:34] <Laurenceb> i.e. no prn clock
[06:35] <Laurenceb> thise can track a signal even if the PLL is off by several 100hz
[06:35] <Laurenceb> and if the DLL is off by several chips
[06:35] <hallam> just to confirm, this is for the prn tracking loop?
[06:36] <Laurenceb> yes
[06:36] <hallam> ok hang on, I'm still trying to get the carrier tracking loop to work
[06:36] <hallam> now it won't correlate
[06:37] <Laurenceb> I'd still go for 1/4 chip i.e. 2 sample spacing
[06:37] <Laurenceb> :P
[06:39] <Laurenceb> sign(real(corrPrompt)
[06:40] <Laurenceb> sign(real(corrPrompt))*real(corrPrompt)
[06:40] <Laurenceb> check the PLL isnt going out of control
[06:43] <hallam> yeah I think I have some bug somewhere, even on the first cycle the correlation isn't right
[06:44] <hallam> grr
[06:46] <hallam> this is annoying
[06:46] <hallam> it used to correlate
[06:47] <Laurenceb> are you chucking the right ammount?
[06:48] <hallam> shouldn't matter for the first cycle
[06:48] <hallam> it won't even cross-correlate
[06:49] <hallam> I guess something's wrong with the carrier
[06:49] <Laurenceb> I meant based on the acquisition
[06:50] <hallam> how many times I chuck shouldn't matter because I'm cross-correlating
[06:51] <hallam> ah yeah wtf, something's definitely wrong with the carrier
[06:55] <hallam> ok fixed
[06:58] <Laurenceb> what does the pll do?
[06:58] <hallam> nothing yet
[06:59] <hallam> the correlation works on the first cycle, tiny on the rest
[06:59] <hallam> I still have no pll filter
[06:59] <hallam> before when I tried this, the correlation stayed alright for 20ms or so
[06:59] <hallam> so something's still screwed with the changes
[07:06] <hallam> okay fixed the carrier
[07:08] <hallam> okay I finally have it all working except for the PLL
[07:08] <hallam> those values of k and l don't seem to work
[07:08] <hallam> is that maybe because teh correlation isn't normalised?
[07:09] <Laurenceb> yeah
[07:10] <hallam> what should I normalise it to?
[07:10] <Laurenceb> also, the NCO function needs to take an argument in rads/sec
[07:10] <Laurenceb> 1
[07:10] rjharrison (n=rharriso@ left irc:
[07:11] <hallam> yeah the NCO does take an arg in rad/s
[07:11] <Laurenceb> you could try arg(corrPrompt)
[07:11] <Laurenceb> but its more cpu cycles
[07:12] <Laurenceb> dunno if normalising then the other discriminator function will be more or less
[07:13] <Laurenceb> can you plot the NCO freq v time?
[07:13] <hallam> well it's rather hard to normalise without knowing what to normalise againse
[07:13] <Laurenceb> erm
[07:13] <hallam> so what should the discriminator be if I want to use arg?
[07:14] <Laurenceb> make the abs =1
[07:14] <Laurenceb> the descriminator is arg
[07:14] <hallam> oh ok
[07:15] <hallam> yeah it seems to pretty much have the same behavior as if there's no loop filter
[07:15] <Laurenceb> so argument or sign(imag(corrPrompt))*real(corrPrompt)/abs(CorrPrompt);
[07:15] <Laurenceb> can you plot the NCO freqency?
[07:16] <hallam> sure hang on
[07:18] Simon-MPFH (n=simon@phantom.mpfh.co.uk) joined #highaltitude.
[07:18] <hallam> http://uploads.mibbit.com/up/BUb00Z9H.png
[07:19] <hallam> the plot of abs(correlation) is similar to what you get without a loop filter
[07:24] <Laurenceb> I may have to lkill my machine
[07:24] <Laurenceb> hang on a sec
[07:25] <hallam> ah it's because we need to track the prn phase and I'm not atm
[07:25] Laurenceb (n=laurence@dyres221-35.surrey.ac.uk) left irc: Remote closed the connection
[07:34] Laurenceb (i=83e3dd23@gateway/web/ajax/mibbit.com/session) joined #highaltitude.
[07:34] <Laurenceb> arg
[07:34] <Laurenceb> linux your crippled by gnuplot
[07:34] <Laurenceb> windows your crippled by antivirus
[07:34] <Laurenceb> anyway, hallam?
[07:34] <Laurenceb> where was that graph
[07:35] <hallam> 1 sec
[07:35] <hallam> http://uploads.mibbit.com/up/zmS5je3i.png
[07:35] <hallam> carrier frequency vs milliseconds, for different gains on the PLL filter between 80 and 120
[07:36] <hallam> the code phase is locked (I just put a good value of prn_clock_offset in, there's no phase loop filter yet)
[07:39] <Laurenceb> different gains between 80 and 120?
[07:39] <Laurenceb> I dont follow
[07:39] <Laurenceb> hmm are we sure we have the right signs?
[07:40] <Laurenceb> as even if its not tuned, the pictures in the book are kind of reversed
[07:40] <Laurenceb> ie. the triangle function is the other way around
[07:43] <Laurenceb> thats odd... the size of those peaks would suggest around30 hz noise bandwidth as well
[07:43] <Laurenceb> something is a bit wrong
[07:44] <Laurenceb> try fiddling with k and l
[07:44] <hallam> ok I flipped the sign, looks a bit better
[07:44] <Laurenceb> :P
[07:44] <Laurenceb> graph grpah
[07:45] edmoore (n=ed@chu-gw.churchillcambridge.co.uk) joined #highaltitude.
[07:45] <Laurenceb> triangles reversed?
[07:45] <edmoore> too early
[07:46] <Laurenceb> hi ed
[07:46] <Laurenceb> we are inverting our triangles (hopefully)
[07:47] <edmoore> for why?
[07:48] <Laurenceb> phase locked loops
[07:49] <edmoore> for why?
[07:49] <Laurenceb> gps
[07:49] <edmoore> with who?
[07:49] <Laurenceb> hallam: what does the graph look like now?
[07:50] <edmoore> oh hoi hernry
[07:50] <edmoore> eeepc keyboards are fiddlier than they look
[07:51] <Laurenceb> yeah, thats the issue with the eeepc
[07:51] <Laurenceb> its too small
[07:51] <Laurenceb> ironically its also the point
[07:52] <hallam> http://uploads.mibbit.com/up/6dQAROWK.png
[07:53] <Laurenceb> omg
[07:53] <Laurenceb> soo close
[07:53] <edmoore> cool
[07:54] <Laurenceb> data 1 looks best
[07:54] <edmoore> hallam: will need the full explanation of this a bit later :)
[07:54] <Laurenceb> guess its complicated by the need to tune two coefficients at once
[07:54] <Laurenceb> are you still using the 10hz frequency bins for aquisition?
[07:55] <Laurenceb> hallam: maybe I mized up the two coefficient
[07:56] <hallam> I've been adjusting them together
[07:56] <Laurenceb> Im not too hot with laplace transforms
[07:56] <Laurenceb> hmm
[07:56] <hallam> I'll try swapping them
[07:56] <hallam> and no, I'm not using the 10hz bins any more
[07:56] <Laurenceb> one varies with B2 and one with B
[07:56] <Laurenceb> erm B^2
[07:56] <Laurenceb> where B is the noise bandwidth
[07:57] <Laurenceb> you need noise bandwidth> the acquisition accuracy it seems
[07:57] <Laurenceb> so the values I worked out were for 60 Hz
[07:58] <edmoore> hallam: are you in the dept?#
[07:58] <hallam> no
[07:58] <hallam> when it's working, the graph of frequency should look like one smooth curve, right?
[07:58] <Laurenceb> yeah
[07:59] <Laurenceb> but its very similar to in the book now
[07:59] <Laurenceb> it appears to be very close to working from what I can see
[07:59] <Laurenceb> but I'd hazard a guess its either initialised wrong or the noise bandwidth is too low
[08:00] <edmoore> can i ask what it is that i'm looking at in that graph?
[08:00] <hallam> doppler frequency estimate vs time
[08:00] <hallam> for one satellite
[08:00] <Laurenceb> this is the hardest bit
[08:00] <Laurenceb> once we've got this working its all downhill :P
[08:01] <edmoore> why the highly discontinuous bits?
[08:01] <Laurenceb> cuz it doesnt work :P
[08:01] <Laurenceb> its "loked" onto the wrong frequency
[08:01] <Laurenceb> thats what causes that behaviour
[08:02] <Laurenceb> but from the examples I'm looking at in borre, it seems to be close
[08:02] <hallam> http://uploads.mibbit.com/up/l18RHBJy.png
[08:02] <hallam> this is with the coefficients exchanged
[08:02] <hallam> does that mean they were right the first time?
[08:02] <Laurenceb> wow wtf
[08:02] <Laurenceb> yeah
[08:02] <hallam> ok
[08:02] <Laurenceb> that looks mega screwed
[08:02] <hallam> I have a slightly better starting freq noqw
[08:03] <Laurenceb> I think data1 from the previous graph was the best looking
[08:04] <edmoore> right, gtg to the dept. good luck, this looks cool.
[08:07] <Laurenceb> hallam: you know that frequency is in rads/sec right?
[08:07] <hallam> yeah
[08:08] <Laurenceb> cool
[08:08] <Laurenceb> I think we can leave it for the time being
[08:08] <hallam> hold on, I'm trying to get an estimate of the frequency trend using acquisition
[08:08] <Laurenceb> its not going out of control
[08:08] <Laurenceb> it could be its losing the PRN a bit
[08:08] <Laurenceb> and thats causing it to lose lock towards the end
[08:09] <hallam> no I think the PRN is fine
[08:09] <Laurenceb> need a dataset of a few seconds
[08:10] <Laurenceb> Borre uses a few hundered ms for testing the PLL
[08:10] <hallam> I don't understand
[08:10] <Laurenceb> longer data
[08:10] <Laurenceb> you can test the stability over a longer time period
[08:10] <hallam> why?
[08:10] <hallam> ij
[08:10] <hallam> ok
[08:10] <hallam> but
[08:11] <Laurenceb> yeah, 150ms is enough to be going on with
[08:11] <hallam> should I be looking at angle(corrPrompt) for the nav bis?
[08:13] <Laurenceb> erm
[08:13] <Laurenceb> no
[08:13] <Laurenceb> for the PLL maybe
[08:13] <Laurenceb> I've got to head off, might be back on in 1/2 an hour
[08:13] <Laurenceb> oh
[08:14] <Laurenceb> for the nav bits
[08:14] <Laurenceb> plot the corrPrompt on the complex plain
[08:14] <Laurenceb> see what it looks like
[08:14] <Laurenceb> I'm off
[08:15] <hallam> ok ttyl
[08:15] <hallam> thanks
[08:17] Laurenceb (i=83e3dd23@gateway/web/ajax/mibbit.com/session) left irc: "http://www.mibbit.com ajax IRC Client"
[08:24] edmoore (n=ed@chu-gw.churchillcambridge.co.uk) left irc: Read error: 110 (Connection timed out)
[08:36] rjharrison (n=rharriso@gateway.hgf.com) joined #highaltitude.
[08:46] Laurenceb (i=83e34f19@gateway/web/ajax/mibbit.com/session) joined #highaltitude.
[08:46] <Laurenceb> hi
[08:46] Action: Laurenceb tucks into bacon sandwich
[08:47] <Laurenceb> the staff canteen here is a*
[08:51] <Laurenceb> http://www.mibbit.com/pb/NBKSLr
[08:51] <Laurenceb> hallam ^
[08:51] Simon-MPFH (n=simon@phantom.mpfh.co.uk) left irc: "Leaving"
[08:51] <hallam> hey
[08:51] <hallam> hmm
[08:51] <Laurenceb> now to find what tau2 and 1 are
[08:53] <hallam> quite
[08:53] <hallam> I've been trying a whole bunch of different values for k and l with not much luck
[08:53] <Laurenceb> http://www.mibbit.com/pb/WjJC8A
[08:54] <Laurenceb> hmm its a bit more complex
[08:54] <Laurenceb> than I thought
[08:54] <Laurenceb> need to work out what PDIcarr is
[08:55] <Laurenceb> oh its the time interval
[08:55] <Laurenceb> 0.001
[08:56] <Laurenceb> ok, so the only thing we dont know is the gain
[08:56] <Laurenceb> ah 1.0 in the code here
[08:58] <Laurenceb> so I'd try a bandwidth of 100 and damping ratio of 0.7
[09:00] <hallam> ok, it gives small numbers
[09:01] <hallam> tau1=2.8e-5, tau2=7.4e-3
[09:01] <Laurenceb> but you use 2/1
[09:01] <Laurenceb> which will be quite large
[09:02] <hallam> what?
[09:02] <Laurenceb> http://www.mibbit.com/pb/WjJC8A
[09:03] <Laurenceb> carrNco = oldCarrNco + (tau2carr/tau1carr) * (carrError - oldCarrError) + carrError * (PDIcarr/tau1carr);
[09:03] <hallam> ok
[09:03] <hallam> and PDIcarr is?
[09:03] <Laurenceb> 0.001
[09:03] <Laurenceb> the time period
[09:05] <Laurenceb> carrNco = oldCarrNco + 264.3 * (carrError - oldCarrError) + carrError*35.71;
[09:05] <Laurenceb> a bit different from before :P
[09:07] <Laurenceb> interestingly this code has a code clock frequency
[09:08] <Laurenceb> and an identical PLL arrangement
[09:08] <Laurenceb> i.e. a second order filter
[09:08] <Laurenceb> I dont get it...
[09:08] <Laurenceb> I'd have though code tracking isnt that hard
[09:09] <Laurenceb> yeah this code seems to use the PRN stretching technique
[09:09] <hallam> http://uploads.mibbit.com/up/ZwsJSm69.png :(
[09:10] jiffe97 (n=jiffe2@ got netsplit.
[09:10] dh (i=dh@bsd.ee) got netsplit.
[09:10] <Laurenceb> what are you using as the descriminator?
[09:11] <Laurenceb> as in what function?
[09:11] jiffe97 (n=jiffe2@ returned to #highaltitude.
[09:11] dh (i=dh@bsd.ee) returned to #highaltitude.
[09:11] <hallam> disc=angle(corrPrompt)/(2*pi);
[09:11] <Laurenceb> hallam: can you plot the NCO freq v time - thats most useful for diagnostics
[09:12] <hallam> http://uploads.mibbit.com/up/IJo9Yn0d.png
[09:12] <Laurenceb> wrong signs
[09:12] <rjharrison> Laurenceb & hallam: I read the logs from last night and I have to say I have no idea what you guys are up too but it sounds very complex
[09:12] <hallam> it's hardly changing
[09:12] <hallam> we're trying to beat the US govt
[09:12] <Laurenceb> you can tell fromt he direction of the trianglesd
[09:13] <Laurenceb> hi rjharrison
[09:13] <hallam> wrong sign of what?
[09:14] <Laurenceb> I'm guessing both loop filter coefficients
[09:14] <rjharrison> have either of you slept in the last 24 hours
[09:15] <Laurenceb> I slept 11 hours ago
[09:15] <hallam> no
[09:15] <Laurenceb> I was sleepign from 4pm to 11pm yesterday
[09:15] <rjharrison> Ok! Have fun guys, I'm way out of my depth here ...
[09:15] <Laurenceb> :P
[09:16] Action: rjharrison heads back to the safe world of databases
[09:18] M0TEK (i=836f0142@gateway/web/ajax/mibbit.com/session) joined #highaltitude.
[09:19] <hallam> okeydoke
[09:19] <M0TEK> how's it going hallam ?
[09:19] <hallam> yeah it seems their discriminator is 180deg from mine
[09:19] <Laurenceb> oh
[09:20] <Laurenceb> so... does it work?
[09:21] <Laurenceb> how do you mean 180 degrees?
[09:22] <hallam> doesn't work yet
[09:22] <hallam> which way should the triangles be going?
[09:24] <Laurenceb> up
[09:24] <Laurenceb> with time
[09:25] <Laurenceb> which would still mean its screwed
[09:25] <Laurenceb> but at least closwe
[09:29] <hallam> oh holy shit
[09:29] <hallam> we almost seem to have it
[09:30] <M0TEK> i am vicariously excited
[09:30] <Laurenceb> omg
[09:30] <M0TEK> hallam: have you lunch plans?
[09:30] <hallam> http://uploads.mibbit.com/up/JZUviSjh.png
[09:31] <hallam> not yet
[09:31] <Laurenceb> oh my god
[09:31] <Laurenceb> data bits
[09:31] <hallam> but but
[09:31] <Laurenceb> scatterplot on the complex plain
[09:32] <hallam> yeah it looks good
[09:32] <hallam> btu
[09:32] <hallam> but
[09:32] <hallam> I don't understand
[09:32] <hallam> it's shifting frequency by a huge amount
[09:32] <Laurenceb> hmm
[09:32] <Laurenceb> can you do a frequency plot?
[09:32] <rjharrison> M0TEK do you want to give a one line sentence as to what Laurenceb and hallam are doing
[09:33] <rjharrison> Nice scatter plot
[09:33] <M0TEK> rjharrison: DIY gps
[09:35] <Laurenceb> hallam: what does PLL v time look like?
[09:35] <M0TEK> hallam: i was gonna say pub lunch but there's pub cuws this eve
[09:37] <hallam> http://uploads.mibbit.com/up/j7fVeJ0e.png
[09:37] <hallam> well whatever, it seems to work
[09:37] <hallam> better run it over the whole file, I think
[09:38] <Laurenceb> hmm
[09:38] <rjharrison> Yowch... And the purpose of making your own gps is ? Appart from being infinitly cool thing to be able to do ...
[09:38] <M0TEK> have you tried an fft of that f vs t?
[09:38] <Laurenceb> +-50Hz
[09:38] <M0TEK> rjharrison: rocket + other stuff we might be doing
[09:39] <Laurenceb> +-10 should be easily achievable
[09:39] <rjharrison> Ie you control the limits etc...
[09:39] <Laurenceb> maybe you want to lower the noise bandwidth
[09:39] <M0TEK> rjharrison: yeah
[09:40] <M0TEK> also there's a theoretical upperlimit of 1khz updates from gps
[09:40] <M0TEK> that's not realistic, but certainly much more than 5hz is.
[09:42] <hallam> not realistic, you say?
[09:42] <M0TEK> real time 1khz updates, yes. I would happily put money on it
[09:42] <M0TEK> for aa practical system to fit in the rocket
[09:43] <M0TEK> getting a whole stack of FPGAs on it consuming 20A does not qualify
[09:43] <M0TEK> before you go off and design the pcb...
[09:43] <M0TEK> you know we're going to have to go the whole hog and make the real time hardware. stick it on the altera cyclone
[09:44] <Laurenceb> you only need one fpga
[09:44] <M0TEK> not for 1khz!
[09:44] <Laurenceb> hmm
[09:44] <Laurenceb> yeah
[09:45] <Laurenceb> it has to run the loops at 1KHz or so
[09:45] <M0TEK> are we talking about a friendly one or a £700 one?
[09:45] <Laurenceb> so if you have a soft core with an FPU
[09:45] <Laurenceb> you can run the loop data straight into the kalman filter
[09:45] <Laurenceb> along with the IMU data
[09:46] <Laurenceb> hallam: try lowering the loop bandwidth to 50Hz
[09:46] <Laurenceb> keep damping ratio at 0.7
[09:46] <Laurenceb> I'm trying with ssoftGNss3 and it looks good
[09:48] <hallam> I don't know what loop bw / damping I'm using, but the results are okay
[09:48] <Laurenceb> hallam: 100
[09:48] <Laurenceb> hallam: ok, yeah its pretty good, but not as good as with softGNSS3
[09:48] <Laurenceb> that uses 30
[09:49] <Laurenceb> but I dont follow the aquisition code
[09:50] <Laurenceb> oh
[09:50] <Laurenceb> theres an intermediate step
[09:50] <Laurenceb> fine level acquisition
[09:51] <Laurenceb> so it uses the data from a 500Hz step acquisition, then goes for a 10ms duration acquisition aligned with the PRN
[09:51] <Laurenceb> 50Hz steps
[09:51] <Laurenceb> allowing a loop bandwidth as low as 25Hz
[09:54] <Laurenceb> guess you might be unlucky and get a nav bin 5ms in
[09:54] <Laurenceb> but this explains why you can go for really small loop bandwidths
[09:55] M0TEK (i=836f0142@gateway/web/ajax/mibbit.com/session) left irc: "http://www.mibbit.com ajax IRC Client"
[09:58] <hallam> I have it tracking to +/-20Hz or so
[09:58] <hallam> need to do the DLL now
[09:59] <Laurenceb> nice, how?
[09:59] <hallam> just fiddled with the gains, didn't bother using calcCoeff
[09:59] <Laurenceb> ok
[10:03] <hallam> so how does the DLL work again? (sorry)
[10:03] <Laurenceb> well
[10:03] <hallam> btw-- it's running at only slightly slower than real time, for one channel
[10:03] <Laurenceb> in softGNSS3
[10:03] <Laurenceb> it has its own clock
[10:04] <Laurenceb> nice
[10:04] <Laurenceb> in c on the blackfin....
[10:04] <Laurenceb> yeah, the softGNSS3 code has a PRN cklock
[10:05] <Laurenceb> then uses a filter just like with the PLL
[10:05] <Laurenceb> IMO its way overcomplicated
[10:05] <hallam> ok I'll try a simple one
[10:05] <Laurenceb> how about PRN_phase+=duiscriminator*gain;
[10:05] <hallam> just let freqoffset=k*corrEarlyLate
[10:05] <Laurenceb> hmm
[10:06] <Laurenceb> well
[10:06] <hallam> which discriminator would you use?
[10:06] <Laurenceb> I'd use real(early_late)
[10:06] <Laurenceb> to start off with
[10:06] <Laurenceb> then if PRN_phase > 1 or <-1
[10:07] <Laurenceb> correct the samples by only dumping 0 or dumping 2
[10:07] <Laurenceb> and correct PERN_phase to zero
[10:07] <Laurenceb> *PRN_phase
[10:07] <Laurenceb> if you want to be clever, have seperate early and late
[10:08] <Laurenceb> and use abs(early)^2-abs(late)^2/abs(early)^2+abs(late)^2
[10:08] <Laurenceb> that can still track if the pll is out by a few hundered hz, and its off by a few chips
[10:14] <rjharrison> Laurenceb: is this a simple explaination of what you're doing? http://users.ictp.it/~radionet/ghana1998/GPS/DECODING.HTM
[10:14] <hallam> yeah
[10:16] <Laurenceb> hmm looks like 25Hz is a typical loop bandwidth
[10:16] <Laurenceb> but as you move to more dynamic environments you want to increaseit
[10:17] <Laurenceb> it all depends on how many g you're going to pull
[10:18] <Laurenceb> 25 Hz is fine for +-0.5g
[10:18] <Laurenceb> i.e. pedestrian/cars
[10:19] <Laurenceb> you want a few hundered Hz for a rocket
[10:30] <Laurenceb> hallam: hows it going?
[10:30] <hallam> gorgeous
[10:30] <Laurenceb> DLL doing something?
[10:31] <hallam> yeah, works nicely
[10:31] <hallam> hold on, I'll get a plot
[10:32] <Laurenceb> plot the PRN_phase v time
[10:33] <Laurenceb> should be some form of triangle wave
[10:37] <hallam> sort of is, but it's not pretty
[10:40] <Laurenceb> 38.400KHz
[10:40] <Laurenceb> is the IF apparently
[10:40] <Laurenceb> sorry if I said 32
[10:40] <hallam> no I think you said 38
[10:40] <Laurenceb> k
[10:40] <hallam> I just wonder where that comes from in the SE4200 datasheet, because I don't see it there
[10:41] <Laurenceb> yeah me too
[10:41] <Laurenceb> http://ccar.colorado.edu/gnss/
[10:41] <Laurenceb> maybe they used a different crystal
[10:44] <Laurenceb> can you plot the PRN_phase variable?
[10:47] <hallam> I did, it's pretty much a triangle wave
[10:48] <hallam> PRN_clock is more interesting
[10:48] <Laurenceb> oh
[10:49] <Laurenceb> you're using a PRN_clock?
[10:49] <Laurenceb> odid you try just changing the phase directly?
[10:51] <hallam> not yet
[10:51] <Laurenceb> I dont follow
[10:52] <Laurenceb> how is the DLL working atm?
[10:56] <hallam> so-so
[10:56] <Laurenceb> as in how
[10:56] <Laurenceb> PRN_Phase
[10:56] <hallam> one sec
[10:56] <Laurenceb> or PRN_clock?
[10:56] <hallam> prn_clock
[10:56] <Laurenceb> ok
[10:56] <hallam> prn_clock=prnclock+k*discriminator;
[10:56] <Laurenceb> interesting
[10:57] <hallam> prn_phase=prn_phase+something*prnclock
[10:57] <Laurenceb> so how do you do the loop filter?
[10:57] <hallam> if prn_phase > something, chuck
[10:57] <Laurenceb> I see
[10:57] <hallam> so it's got integral control
[10:57] <hallam> I'll try it with just proportional
[10:57] <Laurenceb> the first something should be 0.001
[10:57] <hallam> yeah it is
[10:58] <Laurenceb> yeah, my first idea was PRN_phase+=k*discriminator
[11:03] <hallam> yeah I'm trying that now, it works for the strong satellite, not so well for the weak oen
[11:03] <hallam> although I guess that could be carrier tracking
[11:03] <hallam> I haven't succeeded with the weak sat yet
[11:06] <Laurenceb> did you succeed before?
[11:06] <Laurenceb> hmm yeah I guess it is rather sub optimal
[11:06] <Laurenceb> It a bit simpler and theres less to go wrong
[11:07] <Laurenceb> you could try the approach in SDRGNSS3 of a second order filter and a PRN_clock
[11:07] <Laurenceb> but thats got to be an overkill :P
[11:11] <hallam> strong sat is great but I'm not having much luck with the weak one
[11:11] <Laurenceb> even with the PRN_clock?
[11:12] <hallam> haven't tried that yet, I will
[11:12] <hallam> but I don't think it should need it
[11:12] <Laurenceb> how is the PLL behaving with it?
[11:13] <hallam> not great
[11:14] <Laurenceb> hmm maybe you need a low noise bandwidth
[11:16] M0TEK (i=836f0142@gateway/web/ajax/mibbit.com/session) joined #highaltitude.
[11:16] <Laurenceb> annoyingly that decreases high g performance
[11:17] <M0TEK> what's new?
[11:17] <Laurenceb> youre going to have to use the kalman filter state to setup the trackers
[11:17] <Laurenceb> hi, we seem to have a DLL and PLL
[11:17] <Laurenceb> of sorts
[11:17] <M0TEK> i like kalman
[11:18] <Laurenceb> the problem is ... I think ... that you need a high noise bandwidth for the PLL
[11:18] <hallam> I'm not too worried about running it on the rocket at the moment
[11:18] <Laurenceb> to capture high g events
[11:18] <Laurenceb> unfortunately it then doesnt work on weak signals
[11:19] <Laurenceb> so... you need to use the kalman state to control the PLL and DLL
[11:19] <Laurenceb> and the combination of IMU and GPS going into the kalman filter
[11:19] <M0TEK> what are the elements of the kalman state in this case?
[11:20] <Laurenceb> I'd guess something like x,y,z,v_x,v_y,v_z,and a quaternion
[11:22] <Laurenceb> arrange "early" and "late" relative to the timings predicted by the kalman state
[11:24] <hallam> even with lbw = 250, it won't get the weak sat
[11:24] <Laurenceb> you mean 25.0?
[11:24] <hallam> no
[11:24] <Laurenceb> larger lbw means its more noisy
[11:24] <Laurenceb> but can pull in from further away
[11:25] <Laurenceb> to get a weak sat you need a second level of aquisition
[11:25] <Laurenceb> to get within +-25Hz
[11:25] <Laurenceb> i.e. 50 Hz bins
[11:25] <Laurenceb> over 10ms
[11:25] <Laurenceb> thats how SDRGNSS does it
[11:27] <Laurenceb> unfortunately that will lose track if you start pulling a g or so
[11:31] <Laurenceb> so its the limit of what you can use for pedestrian/vehicles
[11:33] <Laurenceb> hallam: I think you need a "level 2 " acquisition
[11:34] <Laurenceb> so you take 20 frequency bins at 50Hz spacing about the acquired 500Hz res bin
[11:34] <hallam> yeah I think I'll do that
[11:34] <Laurenceb> then start at the beginning of a PRN sequence
[11:34] <Laurenceb> and go for 10ms
[11:40] <Laurenceb> hmm I'm still owrking out how to solve the tracking problem at high g
[11:42] <Laurenceb> yuo could use the kalman velocity dotted with the direction to the sat to give a doppler estimate
[11:42] <Laurenceb> then add in clock offset terms
[11:42] <Laurenceb> but how to get a second order filter...
[11:45] <Laurenceb> oh hang on
[11:46] <Laurenceb> if you're running at 1KHz, your PLL can be off by a few hundered Hz
[11:46] <Laurenceb> problem solved
[11:47] <Laurenceb> you should be able to use the kalman state to calculate the NCO frequency and PRN phase/freq
[11:53] <hallam> sweet, the fine acquisition did the trick
[11:53] <Laurenceb> niiicee
[11:53] <Laurenceb> pics
[11:56] <hallam> just closed them, lemme make teh code compile again :P
[11:56] <Laurenceb> compile?
[11:56] <hallam> well, interpret
[12:09] <Laurenceb> any luck?
[12:11] <Laurenceb> hallam: pics
[12:11] <Laurenceb> :P
[12:11] M0TEK (i=836f0142@gateway/web/ajax/mibbit.com/session) left irc: "http://www.mibbit.com ajax IRC Client"
[12:12] <SpeedEvil> m0: Well - you can run the position determination loop way faster than 1KHz if you want. Even 1MHz is quite possible, or 150MHz. Noise'll go way up though.
[12:12] bluenarf (n=Miranda@apollo.paulsnet.org) joined #highaltitude.
[12:12] Nick change: bluenarf -> EI5GTB-School
[12:12] <EI5GTB-School> ohai
[12:13] <Laurenceb> do your homework
[12:13] <EI5GTB-School> nope
[12:15] <hallam> behold: http://uploads.mibbit.com/up/Ket4RVJu.png
[12:16] <Laurenceb> oh my god
[12:16] Action: Laurenceb worships
[12:16] <hallam> that's the strong sat, weak one: http://uploads.mibbit.com/up/0grp9EaV.png
[12:18] <Laurenceb> the strong one is about as good as Borre's example
[12:18] <hallam> note the noise floor on the center plot is about 900 (according to a comment in laurence's code)
[12:19] <Laurenceb> well I was going a bit above the noise floor with that
[12:20] <Laurenceb> ok, next step, search for 01110100 or the inverse
[12:20] <Laurenceb> with each bit repeated 50*8 times
[12:20] <Laurenceb> erm what am I talking about
[12:21] <Laurenceb> 20 times
[12:21] <hallam> heh, more correlation
[12:21] <Laurenceb> doh
[12:21] <Laurenceb> no you do bit sync first
[12:21] <Laurenceb> so you find the first transition where its properly locked
[12:22] <Laurenceb> then after that reduce each group of 20 samples to one bit
[12:22] <Laurenceb> so from your data I'd say look for the first transition after 20ms
[12:22] <Laurenceb> it locks in nice and fast
[12:23] <Laurenceb> then after reducing the data rate to 50bps, look for 01110100 or the inverse
[12:23] <Laurenceb> thats a subframe header
[12:23] <Laurenceb> if you find one you have to check the parity
[12:24] <Laurenceb> if its the inverse header, you invert then check the parity
[12:24] <Laurenceb> and also check for a new header after the parity
[12:24] <Laurenceb> of course you need about 10 seconds of data to do this
[12:25] <hallam> sweet, it also worked perfectly on my other sample file
[12:25] <Laurenceb> so you need a state machine
[12:25] <Laurenceb> cool
[12:26] <hallam> I might leave the nav decoding for now
[12:26] <hallam> tempting as it is
[12:26] <Laurenceb> :P
[12:26] <Laurenceb> yeah I'm going for lunch
[12:26] <Laurenceb> bbl
[12:27] <hallam> so I can do about 1/2 a channel per second, which I'm quite happy with for post-proc
[12:35] EI5GTB-School (n=Miranda@apollo.paulsnet.org) left irc: Remote closed the connection
[12:36] Action: SpeedEvil wonders about his earlier (couple of weeks) question about intentional synchronisation or otherwise of nav messages over satellites.
[12:37] <hallam> by the people who operate GPS?
[12:38] <SpeedEvil> yes.
[12:39] <SpeedEvil> You need 12 minutes to recieve the <wavy lines indicating I've forgotten the word>, but if it was intentionally offset so that groups of satellites broadcast it offset by 1/4, you could do it in 3.
[12:39] <hallam> well, you know about SA\
[12:39] <hallam> oh
[12:39] <hallam> yeah, if you had a full sky
[12:40] <hallam> but you'd have to acquire all the satellites anyway in order to read it
[12:40] <SpeedEvil> And the same with the 6s frames, if they were offset, you could get it in 1.5.
[12:40] <hallam> and if you can do that from a cold start in little time, you don't need the almanac
[12:40] <hallam> here's a question
[12:40] <SpeedEvil> (assuming massively parallel correlators or similar 'instant' approaches.
[12:40] <hallam> I made two recording sessions, one received 2 sats and the other got 3
[12:40] <hallam> in each case, the code phase was decreasing with time
[12:41] <hallam> should I be surprised at that?
[12:41] <SpeedEvil> well...
[12:41] <SpeedEvil> It depends where you are, and what your visibility is.
[12:41] <hallam> vis is shite, I didn't expect to get more sats
[12:41] <SpeedEvil> If you have a view to the <aforementioned wavy lines> you could get only receeding sats.
[12:42] <hallam> south
[12:42] <SpeedEvil> west?
[12:42] <hallam> hm
[12:42] <hallam> east, I guess
[12:42] <hallam> I can see where the sats were
[12:42] <SpeedEvil> maybe
[12:42] <SpeedEvil> also, there is lockal cock drift.
[12:42] Action: SpeedEvil sighs.
[12:42] <SpeedEvil> eeepc is screwing my typing on normal kebs.
[12:43] <hallam> sure, I believe you
[12:44] <hallam> that's what I was wondering, what does the local clock drift do?
[12:44] <SpeedEvil> If your local clock is slow, then it acts like the signals are fast, and hence you can interpret that as doppler coming towards you
[12:44] <hallam> and by drift do you mean (clock_freq - gps_clock_freq), or the time derivative of that
[12:44] <hallam> yeah, doppler on the frequencies, but it shouldn't affect code phase much, should it?
[12:45] <SpeedEvil> of course
[12:45] <SpeedEvil> hang on
[12:45] <hallam> I mean there will be some effect, but I think it's tiny
[12:45] <SpeedEvil> by code phase, you're meaning the position at which the incoming signal correlates with the locally generated PRN
[12:45] <Laurenceb> back
[12:46] <SpeedEvil> correlates maximally
[12:46] <hallam> yeah
[12:46] <hallam> hi laurence
[12:46] <Laurenceb> mmm chicken curry
[12:46] Action: SpeedEvil did a _really_ nice pasta sauce yesterday.
[12:47] <Laurenceb> ok
[12:47] <hallam> the PRN is 300km long, right?
[12:47] <SpeedEvil> hallam: pretty much
[12:47] <Laurenceb> range=65 to 83ms
[12:47] <Laurenceb> so from one data transition
[12:47] <SpeedEvil> a nav bit is the earth long
[12:48] <Laurenceb> brb
[12:48] <SpeedEvil> which is probably not coincidence
[12:48] <hallam> oh, cute
[12:48] <SpeedEvil> err radius
[12:48] <hallam> well it's not exactly
[12:49] <hallam> 5995km vs 6378
[12:50] <Laurenceb> back
[12:50] Action: SpeedEvil is a member of the 6378Km radius earth society. We're a lot saner than the flat earth society.
[12:51] <Laurenceb> 83-65=18ms
[12:51] <Laurenceb> 18ms<20ms
[12:51] <Laurenceb> so if you just have one data transition
[12:51] <Laurenceb> and lookup the ephemeris, you can get the position
[12:52] <Laurenceb> unfortunately without a subframe header you dont know the sat time
[12:52] M0TEK (i=50b1972a@gateway/web/ajax/mibbit.com/session) joined #highaltitude.
[12:53] <Laurenceb> so I'd suggest the easiest thing to do next is a subframe header finder
[12:53] <Laurenceb> MOTEK: we have nav bits :P
[12:53] <SpeedEvil> Or a pps output from a conventional GPS
[12:53] <Laurenceb> http://uploads.mibbit.com/up/Ket4RVJu.png
[12:53] <Laurenceb> lol thats kind of not the point of this
[12:54] <hallam> Laurenceb: I want to understand the code phase vs time plot first
[12:54] <SpeedEvil> Laurenceb: I know :)
[12:54] <Laurenceb> so look for the first transition after about 20ms, then use this to reduce each group of 20 samples to one bit
[12:55] <SpeedEvil> Or look for transistions at integrals of 20 bits over 1s or so, to do much better in noise
[12:56] <SpeedEvil> but you probably don't care about that at first if you're getting adequate signal
[12:56] <Laurenceb> yeah
[12:56] <Laurenceb> I think you lose PLL and DLL first
[12:56] <SpeedEvil> Oooh! sexeh bits!
[12:57] <SpeedEvil> I mean if your signal for 1 bit isn't very high above the noise, to the point you get maybe 15/20 bits correct, you'll have problems with the above scheme.
[12:57] <hallam> do I get the pseudo-range-rate from codeph(1001,:)-codeph(1,:)*300/(1023*8)?
[12:57] <hallam> er codeph(1001,: )-codeph(1,: )*300/(1023*8)
[12:58] <M0TEK> gotta hate smileys
[12:58] <hallam> that should give it in m/s, right?
[12:58] <hallam> it gives some plausible numbers
[12:58] <SpeedEvil> should be +-2Km/s or so
[12:58] <SpeedEvil> IIR
[12:58] <SpeedEvil> C
[12:58] <Laurenceb> arg smilies
[12:58] <hallam> nah, more
[12:58] <Laurenceb> hallam: you use the z count
[12:58] <hallam> the what now
[12:59] <Laurenceb> once you have found a subframe header
[12:59] <Laurenceb> the subframe is made of 30 bit words
[12:59] <Laurenceb> go to the second word
[12:59] <Laurenceb> first 17 bits is the z count
[13:00] <Laurenceb> it gives you sat time in 1.5 sec units
[13:00] <Laurenceb> so z count together with ephemeris gives you sat postiion
[13:01] <SpeedEvil> http://celestrak.com/NORAD/elements/gps-ops.txt
[13:01] <SpeedEvil> gah
[13:01] <Laurenceb> you loop through your sats and find the closest from the phase and subframe header postiion
[13:02] <Laurenceb> set that sat at 68ms pseudorange
[13:02] <Laurenceb> set the others wrt that sat
[13:02] <Laurenceb> initialise yourself at the center of the earth
[13:02] <Laurenceb> solve iteratively
[13:04] <Laurenceb> oh sorry
[13:04] <SpeedEvil> +-600m/s is the most I see today.
[13:04] <SpeedEvil> Thought it was more
[13:04] <Laurenceb> z count is in units of 6 seconds
[13:05] <Laurenceb> so it matches the time interval between subframes
[13:07] <Laurenceb> z count is msb first
[13:09] <Laurenceb> your ging to need about 10s of data or more to do this I think
[13:09] <SpeedEvil> how much is 12 min of data?
[13:09] <Laurenceb> erm a lot
[13:10] <Laurenceb> 11.5GB
[13:10] <SpeedEvil> what is it? 1 bit * ?
[13:10] rjharrison (n=rharriso@gateway.hgf.com) left #highaltitude.
[13:10] <SpeedEvil> oh - i and q, 1 bit *what MHz?
[13:10] <Laurenceb> we only need a subframe to test everything apart from ephermeris collection
[13:10] <SpeedEvil> yeah
[13:11] <Laurenceb> yeah, but the driver saves as schar
[13:12] <Laurenceb> which is a right pain
[13:12] Action: SpeedEvil wishes the Hammerhead chip was documented and available.
[13:12] <Laurenceb> yeah
[13:12] <SpeedEvil> Loop filters and massively parallel correlators and stuff all on chip
[13:12] <Laurenceb> its on the iphone
[13:12] <SpeedEvil> nice simple slow serial interface
[13:13] <Laurenceb> I think we may get a long way on a blackfin
[13:13] <Laurenceb> but ideally we want a fpga with imu/gps
[13:14] <Laurenceb> I hadnt really realised now much your gps performance is reduced simply by making it tolerant to high g
[13:15] M0TEK (i=50b1972a@gateway/web/ajax/mibbit.com/session) left irc: "http://www.mibbit.com ajax IRC Client"
[13:17] <SpeedEvil> Yeah - if you've got even a shitty IMU, it makes it much harder for the loops to be jerked off.
[13:18] <SpeedEvil> off of lock
[13:18] <hallam> so I've been trying to sort out this range-rate issue
[13:18] <hallam> not there yet
[13:18] <Laurenceb> as in PRN_clock?
[13:18] <hallam> I determined the actual range rates from an ephemeris program
[13:18] <Laurenceb> what sort of filter?
[13:18] <SpeedEvil> Range-rate is +-2Km/s, but that's only if you count 1000 knots towards a satellite
[13:18] <hallam> no, as in the observed rate at which prn_phase degreases
[13:18] <hallam> decreases
[13:19] <Laurenceb> yeah, thats PRN_clock
[13:19] <hallam> the actual rates are [-609 494 710] m/s for the 3 sats
[13:19] <SpeedEvil> want me to verify those rates? /me has xephem up.
[13:19] <hallam> sure
[13:19] <SpeedEvil> what prns and times, you're around cambridge?
[13:20] <hallam> 0107 UTC, 21 Jan 09, Cambridge
[13:20] <hallam> PRN 12, 15, 26
[13:20] <Laurenceb> hallam: use the doppler to initialise the PRN_clock
[13:20] <hallam> I got them from Orbitron with a new elset from NORAD
[13:20] <hallam> Laurenceb: sure, I will when I know how to reliably work out the doppler, which is what this is about
[13:20] <hallam> I have solid lock on all 3 sats
[13:21] <Laurenceb> so you want to be sure your range rates are sensible?
[13:21] <hallam> yeah
[13:21] <hallam> and at the moment they're not
[13:22] <Laurenceb> are they stable?
[13:22] <Laurenceb> the PLL looks pretty stable
[13:22] <SpeedEvil> Odd. I get -560,452,652
[13:22] <Laurenceb> but I'd tighten up the loop bandwidth to 25Hz
[13:22] Action: SpeedEvil checks
[13:24] <hallam> Laurenceb: yeah, super stable
[13:24] <Laurenceb> did you go for 25Hz ?
[13:26] <hallam> no, I'll try that while we're thinking
[13:26] <hallam> I'm still using 1st order DLL
[13:27] <hallam> I've been using it at 50Hz
[13:28] <Laurenceb> I was talking about the PLL
[13:28] <Laurenceb> with the second level acquisition you can reset the loop bandwidth to 25Hz
[13:28] <hallam> ok, done that, it's a bit tighter on the frequency
[13:29] <Laurenceb> cool
[13:31] <SpeedEvil> hallam: checked again, I still get teh above numbers with fresh element set.
[13:31] <SpeedEvil> london, england, 0107 this morning, cambridge
[13:32] <SpeedEvil> I've not checked it other ways, but I've used this method before, and it came out with accurate doppler rates (WRT hammerhead research)
[13:33] <hallam> yeah I think orbitron is full of shit
[13:33] <hallam> could you give me the azimuth and elevation you get?
[13:34] <hallam> just for one of the SVs is fine
[13:35] <SpeedEvil> 215,33:160,48:145:28
[13:35] <SpeedEvil> 215,33:160,48:145,28
[13:35] <SpeedEvil> for 12,15,26
[13:36] <hallam> argh I have four different sources telling me four different things
[13:36] <SpeedEvil> :)
[13:36] <hallam> your az/el almost, but not quite match Orbitron, they're quite a lot different to Trimble Planning
[13:36] <SpeedEvil> It's not 1:07 just a few mins ago is it?
[13:37] <hallam> no, 36hrs ago
[13:37] <Laurenceb> hallam: I'm running SDRGNSS3 over vpn
[13:37] <Laurenceb> the DLL works with a second order filter
[13:37] <hallam> cool
[13:37] <Laurenceb> and a code clock
[13:38] <hallam> I don't think it needs to be that complicated, though
[13:38] <Laurenceb> yeah, me too
[13:38] <hallam> the first order filter seems to do the job just fine
[13:38] <hallam> even on weak sats
[13:38] <hallam> as long as you have the fine acquisition
[13:41] <hallam> this is how it looks: http://uploads.mibbit.com/up/5UWuZuAK.png
[13:42] <hallam> I get the code phase by taking (index into file at start of PRN) mod (8184)
[13:43] <Laurenceb> index?
[13:43] <SpeedEvil> hallam: I put london in as the location, so the dopplers and ele/alt will be very slightly off.
[13:43] <Laurenceb> oh into file
[13:44] <Laurenceb> ok
[13:44] <Laurenceb> hallam: can you put the code up on the svr ?
[13:44] <SpeedEvil> london is what - 60 miles?
[13:44] <hallam> about that
[13:44] <hallam> yeah
[13:44] <hallam> do you want to run it or look at it?
[13:45] <hallam> http://uploads.mibbit.com/up/Ak1bI95y.rar here's the lot, apart from the data
[13:45] <Laurenceb> ok, I'll take a look in a sec
[13:45] <Laurenceb> just a sec I'll screenshot SDRGNSS
[13:49] <Laurenceb> http://imagebin.org/36512
[13:50] M0TEK (i=50b1972a@gateway/web/ajax/mibbit.com/session) joined #highaltitude.
[13:51] <M0TEK> Laurenceb / hallam : what's the latest?
[13:51] <hallam> okay fixed the range-rate thing
[13:52] <Laurenceb> what was the problem?
[13:52] <M0TEK> hallam: have a piano lesson from 4 till about 5.30, but could i pop over after?
[13:52] <M0TEK> am keen to get the hand-wavey update
[13:57] <hallam> sure thing
[13:58] <M0TEK> then maybes can try and assist in my own special way
[13:58] <hallam> Laurenceb: I was moduloing by the wrong thing
[13:58] <M0TEK> till maypole
[13:59] <hallam> SpeedEvil: From my measurements, it's -696,403,586
[14:01] <SpeedEvil> cambridge is west of london?
[14:02] Action: SpeedEvil has fuzzy geograpy
[14:02] <hallam> a little north
[14:02] <M0TEK> and slightly east
[14:04] <SpeedEvil> hallam: the relative range-rates are within 20m/s or so
[14:04] <hallam> 52.205, +0.106
[14:04] <hallam> yeah
[14:04] <hallam> oh, they atre?
[14:04] <hallam> the meas uncertainty is 36m/s
[14:04] <SpeedEvil> 0, 1012, 1212
[14:04] <hallam> what's that?
[14:05] <SpeedEvil> 0,1099,1282
[14:05] <SpeedEvil> the relative velocities to the first satellite
[14:05] <SpeedEvil> for my figures, and your ones
[14:06] <SpeedEvil> so add a bit for my location being a bit off, and that comes within 36m/s or so
[14:07] <hallam> can you try setting your location accurately?
[14:07] <SpeedEvil> what's the lat/lon
[14:07] <hallam> 52.205, +0.106
[14:07] <hallam> I still don't understand what 0,1099,1282 means
[14:08] <SpeedEvil> difference from -696
[14:08] <SpeedEvil> between -696,403,586
[14:11] <SpeedEvil> -566,459,658
[14:12] <SpeedEvil> 0,1025,1224 are the rates for cambridge
[14:12] <SpeedEvil> that's better even.
[14:14] <hallam> what are the raw range-rates that you get?
[14:14] <SpeedEvil> the above - -566,459,658
[14:15] <hallam> I don't get why you're allowed to subtract the range-rate to the first satellite
[14:16] <SpeedEvil> I'm assuming your local clock isn't perfect.
[14:16] <SpeedEvil> You generally disregard absolute range rates, as you can't disentangle them from inaccurate clocks.
[14:17] <SpeedEvil> well - unless you have a system like GPS where you know the time.
[14:18] <hallam> okay
[14:18] <hallam> how could I estimate what the expected range rate error due to my clock error is?
[14:18] <SpeedEvil> Decode the bits.
[14:18] <hallam> no
[14:18] <SpeedEvil> Get a clock
[14:18] <SpeedEvil> solve for position
[14:18] <hallam> sure sure
[14:18] <hallam> but
[14:18] <SpeedEvil> get time, get clock error
[14:18] <hallam> say I know my crystal is good to 5ppm
[14:19] <SpeedEvil> Ah
[14:19] <hallam> what can I expect that to mean in terms of range rate
[14:19] <SpeedEvil> 5ppm/c
[14:19] <SpeedEvil> 5ppm*c
[14:19] <hallam> ok
[14:19] <hallam> looks plausible
[14:19] <hallam> thanks so much for the help, btw
[14:19] <SpeedEvil> np.
[14:19] <SpeedEvil> I need to get my hardware sorted.
[14:20] <SpeedEvil> Unfortunately, health and other stuff are getting in the way :(
[14:20] <SpeedEvil> And this is good as it's clearing up my thoughts too.
[14:21] <hallam> oh, sorry to hear you're sick
[14:21] <SpeedEvil> Post-viral fatigue syndrome.
[14:22] <SpeedEvil> I've got a couple of hours a day I can do productive stuff. But if I overdo stuff, I can collapse for weeks, and be able to do little more than wander about in a daze.
[14:22] <SpeedEvil> Not fun.
[14:23] <hallam> damn
[14:24] <hallam> ok so the relative range rates from my measurements are 0 1025 1224
[14:24] <hallam> er sorry
[14:24] <hallam> 0 1081 1337
[14:24] <hallam> subtracting those from yours gives 0 56 113
[14:25] <hallam> I estimate my uncertainty to be 18m/s
[14:25] <SpeedEvil> +-, or total?
[14:25] <hallam> um
[14:25] <SpeedEvil> what's the time including seconds - do you have that?
[14:25] <hallam> total, I think
[14:25] <hallam> heh, not yet
[14:25] <SpeedEvil> I mean - 01:07:??
[14:25] <hallam> yeah I don't know that yet
[14:26] <hallam> do you think the remaining 100m/s can come from time and position uncertainty?
[14:26] <SpeedEvil> 50m/s
[14:26] <Laurenceb> ralative range rates?
[14:26] <SpeedEvil> +-50m/s rather
[14:26] <Laurenceb> how did we get to these beasts?
[14:26] <hallam> range rates to the satellites, minus the range rate to the first sat
[14:26] <Laurenceb> oh, from the DLL?
[14:26] <hallam> you watch the code phase vary over a few seconds
[14:26] <hallam> no it's not from the DLL
[14:26] <Laurenceb> I see
[14:27] <Laurenceb> just from the code phase?
[14:27] <hallam> yeah
[14:27] <hallam> each chip is 36m long
[14:27] <Laurenceb> sure
[14:27] <Laurenceb> and you need relative to account for the clock
[14:27] <hallam> subchip, that is
[14:27] <hallam> right
[14:27] <SpeedEvil> the range rate can vary from +-2m/s or so per min
[14:27] <SpeedEvil> so that's not a big factor
[14:28] <hallam> how about location?
[14:28] <SpeedEvil> a moderate effect
[14:28] <SpeedEvil> the more recent rates were with cambridge as the location
[14:29] <Laurenceb> they are rates to the sat?
[14:29] <Laurenceb> i.e. along the line of sight to the sat?
[14:29] <SpeedEvil> yes
[14:30] Action: Laurenceb has an advert fro "hallam in oxford street"
[14:30] <Laurenceb> google advers are too clever
[14:30] <hallam> yeah the coords I gave you are good to about 0.01 degrees
[14:30] <hallam> which doesn't seem to affect the range rate significantly
[14:30] <hallam> so there's still some uncertainty
[14:30] <SpeedEvil> not really
[14:31] <hallam> maybe because I'm not actually keeping the phase accurate to the subchip?
[14:32] <hallam> I'll integrate over 20 secs, which should cancel that
[14:34] <Laurenceb> why are you doing this?
[14:34] <Laurenceb> surely you can check that its sensible?
[14:35] M0TEK (i=50b1972a@gateway/web/ajax/mibbit.com/session) left irc: "http://www.mibbit.com ajax IRC Client"
[14:36] <hallam> I want to account for the difference between observed and predicted
[14:36] <hallam> it's small, but it's bigger than my predicted uncertainty
[14:37] <Laurenceb> right
[14:40] rjharrison (n=rharriso@gateway.hgf.com) joined #highaltitude.
[14:42] <hallam> hi rjharrison
[14:42] <hallam> SpeedEvil: do you think I should care about this, or not worry? I do want to get my eventually velocity accurate to a few m/s from not too long a sample of data.
[14:43] <SpeedEvil> I would say ignore it.
[14:43] <SpeedEvil> Take a few more samples, get more datapoints
[14:44] <Laurenceb> hallam: use doppler to get velocity
[14:51] <rjharrison> hi hallam
[14:51] <rjharrison> You guys have been doing some serious playing
[14:52] <rjharrison> Is that more fun than UNI work
[14:52] <rjharrison> How did you sample the gps data?
[14:53] <Laurenceb> SIGE sampler
[14:53] <hallam> hi rjharrison
[14:53] <hallam> the nice blue stick from Sparkfun
[14:53] <hallam> sells for $400 atm (I got it when it was a bit cheaper)
[14:53] <hallam> contains $10 of parts, tops
[14:54] <Laurenceb> http://www.sparkfun.com/commerce/product_info.php?products_id=8238
[14:54] <rjharrison> hehe I found it already
[14:55] <rjharrison> googled the sampler
[14:55] <Laurenceb> bah I only have 1s of data
[14:55] <rjharrison> are you saying you could make one for 10$
[14:55] <Laurenceb> hmm 120MB
[14:55] <Laurenceb> yes
[14:55] <rjharrison> Hump I guess that it's so pricy due to lack of demand
[14:55] <Laurenceb> but the plan in to combine it with an FPGA and IMU
[14:56] <Laurenceb> hallam: any way you could send me a 6second data file?
[14:57] <hallam> sure
[14:57] <rjharrison> Cool I think I'll stick to the lassen IQ for the time being
[14:57] <Laurenceb> hallam: can you get 5 sats or so?
[14:57] <hallam> I'll have to reboot
[14:57] <rjharrison> That looks like a headache I just don't need ...
[14:57] <Laurenceb> I'm playing with sdrgnss
[14:58] <rjharrison> Did you get the book that tells you how to process the data
[14:58] <hallam> rjharrison: when I get it working I'll publish schematics and code
[14:58] <hallam> or sell them and give you a copy
[14:58] <Laurenceb> I've got it, hammal has it on order
[14:58] <hallam> haven't heard anyone call me that before
[14:58] <Laurenceb> lol
[14:59] <Laurenceb> I suck at touch typing
[14:59] <hallam> Laurenceb: should I send the file with 3 sats, or do you want to wait 15 mins for me to finish up and reboot to get more sats?
[14:59] <Laurenceb> yeah no probs
[15:00] <rjharrison> Any how you guys are going to be GPS experts after all this
[15:00] Action: Laurenceb looks around at everyone using sdrgnss3 in the office
[15:00] <Laurenceb> I'm surrounded by gps experts
[15:00] <Laurenceb> I'm the gps noob
[15:00] <rjharrison> Do you want to get more samples per second then
[15:01] <Laurenceb> no
[15:01] <Laurenceb> 8M is quite enough
[15:01] <Laurenceb> but I think you mean position updates :P
[15:01] <Laurenceb> in which case yes, we want 1KHz
[15:01] <hallam> rjharrison: when this is done, we should be able to get position updates at many Hz, without the restrictions on altitude/velocity/acceleration
[15:02] <hallam> Laurenceb: I'll wait til 20 past, there should be 6 sats up then
[15:02] <Laurenceb> hopefully 1kHz ultimately
[15:02] <Laurenceb> cool
[15:02] <hallam> Laurenceb: do you think we can get 1kHz without it just being very noisy?
[15:02] <hallam> maybe by going back and forth in time
[15:02] <Laurenceb> yeah
[15:03] <hallam> worry about that later
[15:03] Simon-MPFH (n=simon@phantom.mpfh.co.uk) joined #highaltitude.
[15:03] <Laurenceb> no, using a kalman filter
[15:03] <hallam> [or earlier]
[15:03] <hallam> kalman filter isn't optimal for post-processing though, is it?
[15:03] <Laurenceb> hmm
[15:03] <Laurenceb> its the best way to do it if you have an IMU as well
[15:04] <Laurenceb> and you want to run it in real time on an fpga
[15:04] <rjharrison> Yep I can see that you can make your own guidence system to sell to the terrorists, you I meant position updates did you really mean 1000 per second
[15:04] <Laurenceb> yes
[15:04] <Laurenceb> 1kHz
[15:05] <hallam> Laurenceb: it's not really possible to do 1kHz in real time, is it? shirley someone would have done it by now
[15:05] edmoore (n=edmoore@pomegranate.chu.cam.ac.uk) joined #highaltitude.
[15:05] <hallam> hi ed
[15:05] <Laurenceb> hallam: probably
[15:05] <Laurenceb> but on some military system
[15:05] <edmoore> hi
[15:05] <Laurenceb> with L2
[15:05] <hallam> I guess even the best mil systems don't really need it much faster than 10Hz
[15:05] <hallam> the actuator bandwidth will be less than that
[15:06] <hallam> what they care about is accurate position
[15:06] <Laurenceb> and other groovyness like an 8bit fronmt end
[15:06] <Laurenceb> (for jam resistance)
[15:06] <edmoore> i think 20 is a usual number - i vaguely remember carmack buying one that did that
[15:06] <Laurenceb> yeah
[15:06] <Laurenceb> with attitude sensing
[15:07] <Laurenceb> I just like the concept of a 1KHz kalman filtered IMU
[15:07] <edmoore> who doesn't
[15:07] <Laurenceb> with gps going directly into the estimate
[15:08] <Laurenceb> your signal gets more noisy, but you have more samples
[15:08] <Laurenceb> as long as you dont completely lose the signal
[15:08] <Laurenceb> you're ok
[15:08] <edmoore> 8-bit front ends? gosh that's a lot of data
[15:09] <Laurenceb> yeah, L1 and L2 as well
[15:09] <Laurenceb> then P code generation
[15:09] <Laurenceb> it gets pretty hardcore
[15:10] <Laurenceb> ionospheric correction using L1/L2 phase
[15:10] <Laurenceb> you can get sub one meter in high dynamics
[15:10] <Laurenceb> aka on a jdam
[15:11] <Laurenceb> thus decreasing the number of brown people in the gene pool
[15:11] <SpeedEvil> 3Gbytes/s is no longer a completely scary number.
[15:11] <SpeedEvil> In principle.
[15:11] <SpeedEvil> If you're spending lots of money anyway.
[15:12] <SpeedEvil> +FPGAs. But you're almost never going to need that
[15:13] <SpeedEvil> Even 1KHz vs 10Hz - there is almost no point if you have even a ultra-minimal IMU.
[15:13] <SpeedEvil> I'd personally want to trust the IMU over sub-second intervals more than the GPS anyway.
[15:13] <edmoore> that's probably a fair point
[15:13] <Laurenceb> true
[15:13] <SpeedEvil> GPS jamming is _really_ low power.
[15:13] <Laurenceb> but the two correct one another
[15:14] <Laurenceb> SpeedEvil: try jamming P code with an 8 bit front end
[15:14] <SpeedEvil> True - but the IMU is almost completely accurate sub-second.
[15:14] <SpeedEvil> Laurenceb: Easy!
[15:14] <SpeedEvil> Laurenceb: 34m dish, and a big antenna.
[15:14] <Laurenceb> no
[15:14] <Laurenceb> most certainly not
[15:14] <Laurenceb> lol
[15:14] <SpeedEvil> Pick up the P code directly
[15:14] <Laurenceb> radiation seeking missile
[15:15] <SpeedEvil> For a lot of military applications, GPS jamming isn't really an issue.
[15:15] <Laurenceb> yeah, its too hard
[15:15] <SpeedEvil> Sure, your opponent can jam 100Km radius easily.
[15:15] <hallam> but he has to do that around your launch site
[15:15] <SpeedEvil> But, if you're flying over at 1000km/h, and you have a good inertial fix outside there.
[15:15] <Laurenceb> SpeedEvil: no he cant
[15:15] <SpeedEvil> Then he has a damn good fix anyway.
[15:15] <hallam> so I calculated the range rates from doppler
[15:16] <SpeedEvil> Laurenceb: yes, I know, military stuff is harder to jam
[15:16] <Laurenceb> ok go on
[15:16] <hallam> now the difference between them and SpeedEvil's is about 80m/s
[15:16] <SpeedEvil> Laurenceb: and the new spot-beam systems make it much harder still. I was just pointing out that even if you can jam 100Km, it won't help much.
[15:16] <Laurenceb> hmm
[15:16] Action: SpeedEvil ponders errors.
[15:16] <Laurenceb> hallam: sure you calculated it correctly
[15:17] <Laurenceb> oh hang on
[15:17] <Laurenceb> no clock correction?
[15:17] <SpeedEvil> It was a fresh set of data, downloaded from the NOAA site.
[15:17] <hallam> but the standard deviation of the carrier frequency gives 2m/s
[15:17] <Laurenceb> just the raw doppler rate to each SV ?
[15:17] <hallam> yeah
[15:17] <Laurenceb> ok... lets look at clock
[15:17] <hallam> the clock correction shouldn't affect *relative* range rates, should it?
[15:17] <hallam> or does it
[15:17] <Laurenceb> 400 Hz ?
[15:17] <hallam> maybe it does
[15:17] <SpeedEvil> hallam: a tiny amount
[15:17] <SpeedEvil> hallam: it's a 5ppm error though
[15:18] <SpeedEvil> hallam: so 3mm/s in 600m/s or so
[15:18] <Laurenceb> how does it effect relative?
[15:18] <hallam> Laurenceb is talking about the tx clock correction?
[15:19] <Laurenceb> hmm
[15:19] <Laurenceb> thats not right
[15:19] <hallam> any idea what the absolute error (not stability) in the satellite clock is?
[15:19] <Laurenceb> nope sorry
[15:19] <Laurenceb> shouldnt that database account for it?
[15:20] <Laurenceb> oh it gives velocity
[15:20] <Laurenceb> yeah... I'll look at the ephemeris dataset
[15:20] <Laurenceb> just a sec
[15:20] <hallam> if it's more than about 0.3ppm, that explains it
[15:21] <Laurenceb> yeah, theres correction terms
[15:21] <Laurenceb> its complex
[15:21] <Laurenceb> several time dependant equations for the sat clock
[15:23] <hallam> ok
[15:23] <hallam> well we're getting there
[15:23] <hallam> Laurenceb: I'll take some data for you
[15:23] <hallam> back in 5 mins
[15:23] hallam (i=836fc8c8@gateway/web/ajax/mibbit.com/x-4f36bbee1a1843f6) left irc: "http://www.mibbit.com ajax IRC Client"
[15:23] <Laurenceb> thanks :P
[15:42] edmoore (n=edmoore@pomegranate.chu.cam.ac.uk) left irc:
[15:45] hallam (i=836fc8c8@gateway/web/ajax/mibbit.com/x-3abcd75ce62bed10) joined #highaltitude.
[15:51] <hallam> got some data for you
[15:51] <hallam> just uploading it
[15:51] <hallam> 5 or 6 sats depending on who you ask
[15:51] <Laurenceb> awsome
[15:52] <Laurenceb> I'm just reading through sdrgnss
[15:52] <hallam> (i.e. ask trimble planning, or ask my acq function)
[15:52] <Laurenceb> I think it uses amost exactly the same technique
[15:52] <Laurenceb> of reading variable block sizes
[15:52] <Laurenceb> this is the version off the website
[15:53] <Laurenceb> - well its the version off the CD which I've corrected using some of the files from the site and some from here
[15:53] <Laurenceb> I'll try and zip it for you
[15:54] <hallam> thanks
[15:54] <hallam> my code will track 4 of the 5 sats
[15:54] <hallam> the other one is very weak
[15:54] <Laurenceb> cool
[15:54] <Laurenceb> may be enough
[15:55] <Laurenceb> how long ?
[15:55] <hallam> how should I fiddle with the loop filter to try to track it?
[15:55] <Laurenceb> was the sample
[15:55] <hallam> 40sec
[15:55] <Laurenceb> wow
[15:55] <hallam> I've RARed it down to about 90MB
[15:55] <Laurenceb> ok, not bad
[15:56] <Laurenceb> winrar
[15:56] <hallam> y
[15:56] <Laurenceb> epic winrar
[15:57] <hallam> http://www.srcf.ucam.org/~hmh33/2009_jan22_15h29m43sUTC.rar
[15:57] <Laurenceb> http://uploads.mibbit.com/up/Rq2qfYk5.zip
[15:57] <hallam> heh
[15:57] <hallam> thanks
[15:58] <Laurenceb> brb coffee time
[15:59] <hallam> so how do the PLL properties (LBW, zeta, k) affect its performance, and what should I do to try to lock the weak sat?
[16:00] <Laurenceb> you could try and reduce LBW
[16:00] <Laurenceb> but going below 25 is a bad idea
[16:01] <Laurenceb> zeta controls how much it hunts
[16:01] <Laurenceb> it doesnt seem to have much of an effect wrt weak signals
[16:01] <Laurenceb> k is a measure of NCO sensitivity
[16:04] <Laurenceb> hmm I cant seem to download it
[16:05] <Laurenceb> have you got my code?
[16:05] <hallam> yep
[16:06] <hallam> try my link again? it works for me
[16:06] Action: SpeedEvil tries
[16:06] Action: SpeedEvil slashdots it.
[16:06] <Laurenceb> just says loading....
[16:07] <SpeedEvil> 120k/second
[16:07] <Laurenceb> ok, working now
[16:07] <Laurenceb> no, its jammed at 8%
[16:08] <hallam> wtf
[16:09] <hallam> I downloaded the whole thing
[16:09] <SpeedEvil> Works for me
[16:09] <hallam> I'll try another host
[16:09] <SpeedEvil> downloading 120K/s 10/70M
[16:09] <Laurenceb> stop
[16:09] <Laurenceb> maybe you're using the bandwidth
[16:09] <hallam> it's a decent server
[16:09] <Laurenceb> ok
[16:09] <Laurenceb> must be my end
[16:12] <Laurenceb> I cant get past 8%
[16:13] <hallam> copying it to another server
[16:13] Action: SpeedEvil is at 45%
[16:13] <Laurenceb> thanks
[16:15] <hallam> http://web.mit.edu/~hallam/www/2009_jan22_15h29m43sUTC.rar
[16:18] <Laurenceb> its working
[16:18] Action: SpeedEvil wonders what Laurencebs problem was.
[16:18] <SpeedEvil> Do you have a content filter on your line?
[16:19] <Laurenceb> yeah
[16:19] <SpeedEvil> Stupid filters can filter on strings which randomly occur in large binaries
[16:19] <Laurenceb> "stop looking at ebay and do some work"
[16:20] <SpeedEvil> hallam: what is the sampling rate and format of this file? /me needs to do some coding.
[16:21] <SpeedEvil> (and this file is really handy)
[16:21] <hallam> format: I,Q,I,Q,...
[16:21] <hallam> where each is either 1 or -1
[16:22] <hallam> so read it as a series of signed bytes
[16:22] <hallam> Fs = 8.1838 MHz IF = 38.400 kHz
[16:22] <SpeedEvil> Sounds simple enough
[16:22] <SpeedEvil> Many thanks.
[16:23] <Laurenceb> speedEvil: if you have matlab, you can use my olink
[16:23] Action: SpeedEvil does not.
[16:23] Action: SpeedEvil was planning on C
[16:23] <SpeedEvil> FFT is pointless for me
[16:23] <SpeedEvil> as my hardware can absolutely not do that.
[16:23] <SpeedEvil> well - absolutely may be strong - but...
[16:24] <Laurenceb> download done
[16:24] <SpeedEvil> Me too. testing rar now
[16:24] <Laurenceb> now I have to move it onto an undergrad ee lab pc
[16:25] <Laurenceb> where I can run matlab from
[16:26] <hallam> it's a tough life
[16:26] <Laurenceb> hmm someone is running firefox on this one
[16:26] <Laurenceb> say goodby to your cpu noob
[16:27] Action: Laurenceb evil laugh
[16:31] <SpeedEvil> The mechanical properties and research into structure of spider silk - material world R4 now
[16:33] Hiena (n=Hiena@ joined #highaltitude.
[16:33] <Laurenceb> hmm they are a bit weak
[16:35] <Laurenceb> what sats were visible?
[16:38] <hallam> [11,13,20,23,32]
[16:38] <hallam> those are the ones I can find, anyway
[16:38] <Laurenceb> ok
[16:39] <Laurenceb> hmm sdrgnss sucks
[16:39] <Laurenceb> only finds 13
[16:39] <hallam> planning says 17 might be up, too
[16:39] <hallam> I can find and track all but 20
[16:40] <Laurenceb> oh actually it finds 13, 11, and23
[16:40] <hallam> interesting, Planning says 20 is right overhead
[16:40] <Laurenceb> 20 is really weak
[16:41] <Laurenceb> I'll wait for it to run the tracking
[16:41] <hallam> it's found 20 too?
[16:41] <Laurenceb> no
[16:41] <Laurenceb> its right down in the noise
[16:43] <Laurenceb> I'm going to find out where you live
[16:43] <Laurenceb> (hopefuilly)
[16:44] <Laurenceb> have you got my code running?
[16:47] <hallam> haven't looked at it yet :P
[16:47] <hallam> I'm improving the acq routine
[16:47] <Laurenceb> hmm
[16:47] <Laurenceb> I cant track 23
[16:48] <hallam> if you integrate over more than 1 ms, you get N peaks in the mesh plot
[16:48] <hallam> you can collapse it along the code phase axis by a factor of N, which should improve SNR
[16:52] <Laurenceb> ok.. I've told it to only look for the visable sats
[16:52] <Laurenceb> it looks like there could bwe a bug in the doppler search, it goes too far
[16:58] <hallam> how far?
[16:58] <hallam> I'm doing +/- 20kHz
[16:58] <Laurenceb> well its giving my MHz
[16:58] <Laurenceb> but the configuration file is +-10KHz
[16:58] <Laurenceb> sorry +-7
[16:59] <Laurenceb> so I may swap it to +-10
[16:59] rjharrison (n=rharriso@gateway.hgf.com) left irc:
[17:00] <Laurenceb> something is def screwy
[17:01] jcoxon (n=mirggi@ joined #highaltitude.
[17:01] <jcoxon> Afternoon
[17:01] <SpeedEvil> Afternoon, and welcome to the software GPS channel.
[17:02] <Laurenceb> hi
[17:02] <jcoxon> Software gps! Oh dear, sounds technical
[17:02] <hallam> but oh so promising
[17:03] <jcoxon> Will browse the logs later
[17:03] <jcoxon> Oh cool
[17:03] <Laurenceb> :P
[17:03] <Laurenceb> I can only get 11 and 13
[17:04] <Laurenceb> I'll try again with different doppler limits
[17:05] <jcoxon> Glad you guys are keeping busy.
[17:05] <jcoxon> Just so the channel doesn't get upset need to stick the word balloon occasionally!
[17:06] <jcoxon> Oops there needs to be an 'in' in that sentence
[17:08] <jcoxon> Henry is this for the rocket to avoid the normal limits?
[17:08] <Laurenceb> hallam: are you sure about those?
[17:08] <Laurenceb> as the observable ats
[17:09] <hallam> yeah man
[17:09] <hallam> I tracked all of them btu 20
[17:09] <hallam> jcoxon: yes
[17:09] <jcoxon> Cool
[17:11] <jcoxon> Bbl
[17:11] jcoxon (n=mirggi@ left irc:
[17:15] Hiena (n=Hiena@ left irc: "-=Halt! Hammerzeit!=-"
[17:21] Bluenarf (n=Paul@apollo.paulsnet.org) joined #highaltitude.
[17:22] Nick change: Bluenarf -> EI5GTB
[17:24] borism (n=boris@195-50-199-218-dsl.krw.estpak.ee) joined #highaltitude.
[17:30] borism_ (n=boris@195-50-197-56-dsl.krw.estpak.ee) left irc: Read error: 145 (Connection timed out)
[17:35] <hallam> Laurenceb: any luck finding sv 20?
[17:36] <hallam> I had it in acquisition before, but I can't find it now, and I didn't keep a backup
[17:36] <Laurenceb> nope
[17:36] <Laurenceb> there a bug in the sdrgnss code
[17:36] <Laurenceb> its finding crazy dopplers
[17:41] <Laurenceb> hmm segmentation fault
[17:42] <Laurenceb> please restart
[17:43] jcoxon (n=jcoxon@host86-158-31-172.range86-158.btcentralplus.com) joined #highaltitude.
[17:44] <Laurenceb> now it wont die
[17:44] <Laurenceb> woops
[17:44] <hallam> ok, got it back
[17:44] <hallam> depends where in the data file you start
[17:44] <Laurenceb> sv20 ?
[17:44] <Laurenceb> minght be fading in and out
[17:45] <hallam> yeah, or I tried to acq over a nav bit transition
[17:45] <Laurenceb> ah yeah
[17:45] <Laurenceb> theres a possibility that might happen
[17:45] <Laurenceb> you may want to try at two locations
[17:45] <hallam> yeah
[17:45] <hallam> it's got a lot of doppler on it, too
[17:46] <Laurenceb> odd when its overhead
[17:46] <hallam> maybe it's just not there at all
[17:46] <hallam> yeah
[17:46] <Laurenceb> can you see nav bits?
[17:46] <hallam> no, I can't lock the PLL on it
[17:46] <Laurenceb> but you get a peak?
[17:47] <hallam> only the tiniest of one
[17:48] <hallam> and the doppler is totally wrong, it thinks it's got 2km/s of range rate
[17:48] <hallam> and it's overhead
[17:48] <Laurenceb> hmm
[17:48] <Laurenceb> very odd
[17:48] <hallam> yeah I think it probably wasn't there
[17:48] <Laurenceb> were you holding the ant horizontal?
[17:48] <hallam> not quite
[17:49] <hallam> and it was against my window
[17:49] <hallam> there's a very real chance that it can't see overhead
[17:49] <Laurenceb> oh
[17:49] <Laurenceb> ok, may explain the issues
[17:49] <hallam> it's like 5 degrees off zenith, but in the wrong direction
[17:49] <hallam> it's probably just noise
[17:49] <hallam> I'll increase the threshold a smidge
[17:49] <Laurenceb> I've found window sills are a suprisingly poor place to get signal
[17:50] <jcoxon> wow - have you guys been working on this for nearly 24hrs?
[17:50] <Laurenceb> yeah
[17:51] <Laurenceb> can you track 23 ?
[17:52] Action: SpeedEvil has been working on it for a decade (sorta)
[17:52] <Laurenceb> SpeedEvil: how old are you?
[17:52] <SpeedEvil> ~30
[17:52] Action: SpeedEvil is old.
[17:54] <SpeedEvil> Somewhere I have a partial hardware GPS.
[17:55] <SpeedEvil> Well - it was designed as a timing source
[17:55] <SpeedEvil> TTL PRN generators, ...
[17:55] <SpeedEvil> Diddn't get very far tholguh.
[17:56] <hallam> Laurenceb: no problem tracking 23
[17:56] <hallam> it's the strongest, I think
[17:58] <hallam> actually 11 is stronger
[17:58] <hallam> 32 is pretty weak
[18:00] <Laurenceb> hmm
[18:00] <Laurenceb> ok, I just went downstairs and spoke to someone whos used sdrgnss
[18:01] <Laurenceb> apparently there may be some issues
[18:01] <Laurenceb> I'm swapping some files
[18:05] <Laurenceb> looks like the fine acquisition is buggy
[18:05] <Laurenceb> wound explain why it suddenly gave me -1.2MHz doppler
[18:24] <EI5GTB> you "went downstairs" ?
[18:24] <EI5GTB> i want to be where you are :P
[18:24] <SpeedEvil> He has a basement with a GPS geek locked in it.
[18:25] <SpeedEvil> hj: use lube
[18:25] <SpeedEvil> oops
[18:35] <Laurenceb> no he cant fix it
[18:36] <Laurenceb> its giving -ive dopplers
[18:46] edmoore (n=edmoore@pomegranate.chu.cam.ac.uk) joined #highaltitude.
[18:47] <hallam> hi ed
[18:52] <edmoore> hi henry
[18:53] <edmoore> what news?
[18:56] <edmoore> hallam: ping
[18:57] <jcoxon> evening edmoore
[18:57] <Laurenceb> [fftMax, fftMaxIndex]
[18:57] <Laurenceb> what does that mean in matlab?
[18:57] <Laurenceb> in creates a matrix?
[18:58] Tigga (n=chatzill@pc-232-235-103.magd.cam.ac.uk) joined #highaltitude.
[19:00] <edmoore> Laurenceb: what's the latest?
[19:00] <Laurenceb> theres a bug in sdrgnss3
[19:00] <Laurenceb> cant work out where hallam lives
[19:00] Action: SpeedEvil ponders a prize.
[19:00] <hallam> I'm being perfectionist over my acquisition routines
[19:01] <SpeedEvil> You post a GPS raw capture, and someone has to tell you where it is and supply nice source code to decode the position.
[19:01] <Laurenceb> been done before
[19:04] <Laurenceb> hallam: you need to move on top nav bit decoders
[19:04] <jcoxon> hehe just got a vehicular manslaughter on halo 3 - gosh i'm being productive
[19:07] <Laurenceb> I've had enough of this
[19:07] <Laurenceb> time to get food
[19:09] <Laurenceb> I think my "gps expert" has completely screwed the code
[19:09] <Laurenceb> its using an fft based fine acquisition
[19:10] <Laurenceb> but theres seemingly no sanity checks
[19:11] <Laurenceb> to stop it going to -ine doppler ect
[19:11] <Laurenceb> anyway, bbl
[19:11] Laurenceb (i=83e34f19@gateway/web/ajax/mibbit.com/x-90efe4b626cd3ddd) left irc: "http://www.mibbit.com ajax IRC Client"
[19:38] edmoore (n=edmoore@pomegranate.chu.cam.ac.uk) left irc:
[19:57] Laurenceb (i=83e3dd23@gateway/web/ajax/mibbit.com/x-f0a8cab886fd7b84) joined #highaltitude.
[19:57] <Laurenceb> hello
[19:58] <Laurenceb> hallam: ping
[20:00] simon__ (n=simon@phantom.mpfh.co.uk) joined #highaltitude.
[20:02] Simon-MPFH (n=simon@phantom.mpfh.co.uk) left irc: Read error: 104 (Connection reset by peer)
[20:10] <Laurenceb> how goes it?
[20:18] <Laurenceb> are you sure you can track 4 sats in that dataset?
[20:22] simon__ (n=simon@phantom.mpfh.co.uk) left irc: Read error: 104 (Connection reset by peer)
[20:22] simon__ (n=simon@ joined #highaltitude.
[20:40] RocketBoy (n=Steve@ joined #highaltitude.
[20:51] rjharrison (n=rharriso@ joined #highaltitude.
[20:51] <rjharrison> Hi all
[20:53] <hallam> hey
[20:54] <hallam> Laurenceb: yes, definitely tracks 4
[20:54] <hallam> I'm working on the nav decoding
[20:54] <Laurenceb> hmm
[20:54] <hallam> it's a little harder than you might think, for noisy data
[20:54] <Laurenceb> yeah I'm still trying to fix my acquisition code
[20:55] <Laurenceb> look across the sample of the bin transip place
[20:55] <Laurenceb> i.e. where theres the most shift in output if you sum delta(real(prompt)) over 20ms intervals
[20:56] <Laurenceb> then you can reduce down to 50bps
[20:56] <Laurenceb> and look for the headers
[20:57] <rjharrison> Hi RocketBoy
[20:59] <Laurenceb> you'll have it working before I've even got sdrgnss fixed
[21:01] <Laurenceb> you could average the samples across each 20ms interval
[21:01] <Laurenceb> once you've found the transit point
[21:22] jcoxon (n=jcoxon@host86-158-31-172.range86-158.btcentralplus.com) left irc: "Leaving"
[21:30] simon__ (n=simon@ left irc: "Leaving"
[21:38] jcoxon (n=jcoxon@host86-158-31-172.range86-158.btcentralplus.com) joined #highaltitude.
[21:52] <rjharrison> steve pm
[21:54] <natrium42> hi
[21:54] jcoxon (n=jcoxon@host86-158-31-172.range86-158.btcentralplus.com) left irc: "Leaving"
[22:00] borism (n=boris@195-50-199-218-dsl.krw.estpak.ee) left irc: Client Quit
[22:10] <fergusnoble> hallam: whats new?
[22:18] <Laurenceb> hmf
[22:18] <Laurenceb> cant get more than 2 sats
[22:18] <Laurenceb> what are your dopplers?
[22:23] <Laurenceb> I'll record my own data I think
[22:24] <Laurenceb> and not out of a window :P
[22:30] <hallam> fergusnoble: can lock onto satellites (apparently better than the code with the book can), find their dopplers, just reading the nav message now
[22:30] <fergusnoble> sweet
[22:30] <fergusnoble> and code phase?
[22:30] <hallam> yeah
[22:30] <hallam> at the moment post-processing is about 8x slower than real-time, depending on how many satellites
[22:30] <fergusnoble> thats really cool
[22:31] <fergusnoble> so in theory with soe splamentary data yo could calclate a fix from that?
[22:31] <hallam> Laurenceb: Do you know what is the shortest length of time I have to wait to ensure there's a nav msg bit transition?
[22:31] <hallam> yeah, and soon the nav msg will give us the supplementary data
[22:31] <fergusnoble> cool
[22:35] <Laurenceb> hallam: 20ms
[22:37] <Laurenceb> bbl
[22:42] <Laurenceb> hallam do you have dopplers
[22:42] <Laurenceb> soI can check my code
[22:45] <Laurenceb> 23 and 32 wont lock
[22:45] <hallam> oh sure, one sec
[22:45] <hallam> Laurenceb: it's longer than 20ms though
[22:45] <hallam> how long to guarantee a transition?
[22:45] <Laurenceb> Id go outside and try
[22:45] <Laurenceb> but its raining
[22:45] <Laurenceb> oh
[22:45] <Laurenceb> depends...
[22:46] <Laurenceb> about 20 bits
[22:46] <hallam> ve are acqviring ze satellites
[22:47] <hallam> I don't actually need a fine aquisition for this dataset
[22:47] <hallam> but I'll run one just for you
[22:47] <Laurenceb> :P
[22:48] <hallam> http://www.mibbit.com/pb/67bYtP
[22:48] <hallam> ignore the phase, it's meaningless
[22:48] <Laurenceb> k
[22:48] <Laurenceb> just a sec, on the phone
[22:56] <hallam> ok I have nice solid nav bit recovery now
[23:00] <fergusnoble> hallam: how hard is it to use the data you recover?
[23:00] <fergusnoble> im guessing thats a large part of it
[23:00] <hallam> I think the hardest part is done
[23:00] <fergusnoble> wow
[23:01] <fergusnoble> this is so exciting
[23:01] <hallam> just a whole pile of vector maths now
[23:01] <fergusnoble> ok
[23:05] <Laurenceb> back
[23:05] <Laurenceb> the maths is kind of like a extended kalman filter
[23:06] <Laurenceb> hence why I came up with the kalman filter IMU/GPS plan
[23:06] <Laurenceb> also of course we now know about the PLL tracking issue at high g
[23:06] <Laurenceb> hallam: I just realised how totally shite this fine acquisition code from the book is
[23:06] <hallam> is there something like a kalman filter but noncausal?
[23:06] <hallam> hehe
[23:07] <hallam> do you want my code?
[23:07] <Laurenceb> nah its ok
[23:07] <Laurenceb> probably simpler to fix this
[23:07] <Laurenceb> it just takes out the code then FFT
[23:07] <Laurenceb> and find the highest peak
[23:07] <Laurenceb> no use of the course result
[23:07] <hallam> interesting, my tracker loses lock on SV 32 after 25 seconds
[23:08] <Laurenceb> its very weak
[23:08] <hallam> yeah
[23:08] <Laurenceb> my course filter doesnt even get the right dopplers for 23 and 32
[23:08] <Laurenceb> how are you doing it?
[23:09] <Laurenceb> oh hang on... I'm not 100% sure about that
[23:09] <Laurenceb> need to run again with more comments
[23:10] <Laurenceb> using xming is too slow :-/
[23:13] <fergusnoble> ok... how can including an h file add nearly 5k to the amount of ram a piece of code uses?
[23:13] <Laurenceb> erm
[23:13] <Laurenceb> if its contains stuff that shouldnt be there
[23:15] <Laurenceb> interesting
[23:15] <Laurenceb> my course aquisition fails
[23:15] <Laurenceb> might explain things
[23:15] <Laurenceb> it doesn aquire 23 or 32
[23:16] <Laurenceb> hallam: what are the parameters for your course aquisition?
[23:17] <Laurenceb> actually, it only gets 23 wrong
[23:21] <hallam> fergusnoble: if it declares functions that aren't used in the code, they may still be linked in from libraroes
[23:21] <hallam> Laurenceb: let me see
[23:21] <hallam> coarse acq parameters:
[23:21] <fergusnoble> hallam: that shouldnt affect ram usag, but i think ive found part of the problem
[23:21] rjharrison (n=rharriso@ left irc:
[23:22] <hallam> searches 38000Hz +/- 15000 in bins of (500/milliseconds)Hz
[23:22] <hallam> and I'm using 4ms
[23:22] <Laurenceb> yeah, they are only compiled if you use them in the code
[23:22] <Laurenceb> aha
[23:22] <Laurenceb> 4ms
[23:22] <Laurenceb> no wonder
[23:22] <hallam> yeah that helps
[23:22] <hallam> what were you on?
[23:22] <Laurenceb> 1
[23:23] <Laurenceb> I think fixined the dodgy fine code will let me get 32
[23:23] <Laurenceb> but 23 is off by a long way for some reason
[23:31] RocketBoy (n=Steve@ left #highaltitude.
[23:32] <Laurenceb> hmf
[23:32] <Laurenceb> fixed the fine acquisition
[23:32] <Laurenceb> but still no luck
[23:37] edmoore (n=edmoore@pomegranate.chu.cam.ac.uk) joined #highaltitude.
[23:38] EI5GTB (n=Paul@apollo.paulsnet.org) left irc: Read error: 104 (Connection reset by peer)
[23:38] <Laurenceb> hallam: whats that fft theorem?
[23:38] <Laurenceb> if I have some cacode
[23:38] <Laurenceb> then upsample it
[23:38] <Laurenceb> say 8 times, what happens to its fft?
[23:40] <edmoore> yo
[23:40] <Laurenceb> hi edmoore
[23:40] <edmoore> a random if i can help - i've just done fft's formally
[23:40] <edmoore> though they're still not quite in the nogin
[23:40] <Laurenceb> so I have some set of data
[23:40] <Laurenceb> a,b,c,d
[23:41] <Laurenceb> becomes a,a,b,b,c,c ect
[23:41] <Laurenceb> what happens to the fft?
[23:41] <edmoore> abcd are discrete time measurements?
[23:41] <fergusnoble> edmoore: hello
[23:41] <edmoore> hi fergusnoble
[23:41] <Laurenceb> yes
[23:41] <edmoore> did you get back ok?
[23:41] <fergusnoble> edmoore: slashin the ram usage of the badger code
[23:41] <fergusnoble> yeah, just fime
[23:42] <fergusnoble> you took your time
[23:42] <edmoore> fergusnoble: cool. Found the other 9kb?
[23:42] <edmoore> I got waylayed
[23:42] <fergusnoble> i think it wasnt actually there, it was crossworks reporting usage for extern'd variables more than once
[23:42] <edmoore> Laurenceb: god question
[23:42] <hallam> Laurenceb: if fft([a b c d]) = [e f g h]
[23:42] <edmoore> i'll get some paper out
[23:43] <fergusnoble> but there is still a lot of waste
[23:43] <hallam> then fft([a b c d a b c d]) = 2*[e 0 f 0 g 0 h 0]
[23:43] <Laurenceb> ok
[23:43] <Laurenceb> how do I do that, upsample?
[23:43] <hallam> yeah
[23:43] <edmoore> that's different to aabbccdd though
[23:43] <hallam> yes, presumably you'd want what I said
[23:43] <hallam> if you're doing something different, I don't know
[23:44] <hallam> I only worked that out empirically
[23:44] <Laurenceb> caCodeFreqDom = upsamle(conj(fft(caCodesTable(PRN, :))),4);
[23:44] <Laurenceb> to go from 1ms to 4
[23:44] <Laurenceb> caCodeFreqDom = upsamle(conj(fft(caCodesTable(PRN, : ))),4);
[23:44] <natrium42> edmoore, need any PCBs made with gold phoenix?
[23:44] <edmoore> that kind of upsampling is a bit scary
[23:44] <natrium42> i am going to make an order next week
[23:44] <edmoore> natrium42: we will need to soon
[23:45] <edmoore> yeah we might be ready for then
[23:45] <natrium42> k, cool
[23:45] <Laurenceb> HASL
[23:45] <natrium42> i will keep you updated
[23:45] <edmoore> Laurenceb: you can't really upsample by just doing a zero-order hold repetition
[23:45] <edmoore> well, you can, but you have to filter out the resulting harmonics
[23:46] <Laurenceb> I'm not
[23:46] <Laurenceb> abcdabcdabcd
[23:46] <Laurenceb> is whats happening in time domain
[23:46] <edmoore> oh ok
[23:46] <edmoore> that's fine
[23:46] <natrium42> Laurenceb, need any PCBs made?
[23:46] <Laurenceb> wish I did
[23:47] <Laurenceb> actually if anyone want some radios
[23:47] <Laurenceb> any takers?
[23:47] <edmoore> so what's the question - how to take the fft of that finite data set?
[23:47] <hallam> radios?
[23:47] <natrium42> what radios?
[23:47] <SpeedEvil> Laurenceb: are they nice DAB ones, with good speakers?
[23:47] <Laurenceb> avr radio module
[23:47] <SpeedEvil> Laurenceb: :)
[23:47] <natrium42> Laurenceb, do they work for HAB?
[23:47] <Laurenceb> the v2 board
[23:47] <Laurenceb> indeed
[23:47] <SpeedEvil> ecl: I was meaning WRT the recert comment
[23:47] <SpeedEvil> oops
[23:47] <Laurenceb> its designed to slot into the bottom of a mega168
[23:47] <Laurenceb> erm
[23:48] <edmoore> anyhoo, I was just going to mention windowing functions
[23:48] <Laurenceb> radiometrix
[23:48] <Laurenceb> and has a mega168 onboard
[23:48] <Laurenceb> any takers?
[23:48] <Laurenceb> I may as well get one
[23:48] <edmoore> you pretend your finite data set is infinite, just so the maths works, but convolve it with some windowing fuction that is non-zero for some amount of time that's less than the length of your data set
[23:48] <Laurenceb> do gold phoenix do routing?
[23:49] <natrium42> Laurenceb, i don't really need it (since that frequency is not license free in canada)
[23:49] <natrium42> Laurenceb, yeah
[23:49] <natrium42> tab routing
[23:49] <edmoore> different windowing functions can produce different harmonic effects - the 'hamming' window is the standard one to get nice valid results fairly easily
[23:49] <Laurenceb> k
[23:49] <Laurenceb> edmoore, hallam?
[23:49] <Laurenceb> radios?
[23:49] <edmoore> we're ok on the radio front I think, thought thanks
[23:49] <Laurenceb> kewl
[23:50] <Laurenceb> natrium42: is just the one ok with you?
[23:50] <edmoore> that reminds me - hallam: we (ferg and I) found out from michael at CUWS that the ic-7000 can be modded to TX on all freqs
[23:50] <Laurenceb> whats the finish? HASL ?
[23:50] <natrium42> Laurenceb, sure, just send me teh data
[23:50] <natrium42> is it eagle format?
[23:50] Action: Laurenceb traws about his hdd
[23:50] <Laurenceb> yes
[23:50] <edmoore> by default it's limited just to licensed bands
[23:51] <edmoore> that means we can easily work with 169
[23:52] <hallam> nice
[23:55] <Laurenceb> natrium42: email?
[23:56] <natrium42> sure, that works the best
[23:56] <natrium42> natrium @ gmail . whatever
[23:56] <natrium42> bbl
[23:57] <natrium42> btw, there's silk screen too, if you want to put anything there
[23:57] <natrium42> i am going to gold plate them
[23:57] <natrium42> bbl
[23:57] <Laurenceb> sent
[23:57] <Laurenceb> its a bit of a mess
[23:57] <Laurenceb> I should keep my files organised
[23:58] <Laurenceb> dasically its the v2 stuff
[23:58] <Laurenceb> and there should be a single pot on the board
[00:00] --- Fri Jan 23 2009